Category Archives: Blog

General thoughts on life, the universe and everything. Stuff that doesn’t fit in the other categories!

Blog

Facts and Fallacies of Software Engineering

I’ll be honest: I wanted to like “Facts and Fallacies of Software Engineering” by Robert L. Glass more than I did. I’m not sure if it’s dated badly — it’s from 2002 — or I was in the wrong frame of mind, or something else, but it just didn’t work for me.

The book is structured as a list of facts grouped around areas such as “Management” and “Requirements.” For each fact, there is a discussion, the controversy, and then the sources and references. The writing aims to be friendly, but I found it a bit grating1.

Going back through the fifty-five facts and fallacies, I find that I agree with the majority of them2. Twenty years on from the original version, I suspect that some are less controversial than when it was originally published. There is some degree of (justified) scepticism about the newfangled “agile” process, which is now largely standard across the industry. Yet it’s also reassuring how little other things have changed. There is still little transfer between academia and industry. Quality continues to be a hot-button topic. And software maintenance rarely gets the love it deserves.

I’ve seen this book described as a classic, so maybe I’m missing something. There are many books I would suggest you read first. In the end, I didn’t like the writing, and I think that there are too few original insights in too many words.

  1. This is such a subjective thing. I think the objective in was modesty or self-deprecation, but it came across as boasting. ↩︎
  2. I’m resisting the temptation to argue against those that I don’t agree with. ↩︎
Blog

Maker, Manager and Consultant Schedule

Have you heard about the Maker Schedule? The idea resonated as it explained a lot about my productivity.

For the uninitiated, here are how the two types are defined.

The manager’s schedule is [where] each day [is] cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

The Maker’s schedule, on the other hand:

[Makers] generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

The challenge I have is that I’m neither a maker nor a manager. As a “consultant”1 I fall somewhere between the two. The variety is what makes it interesting to me. The variety is also what makes it difficult.

Sometimes I have to sit and concentrate for a large block of time. Maybe I’m sketching out an architecture, researching something, building a prototype, or debugging some code. Perhaps I’m writing a report or putting together a presentation.

On other days I have back-to-back meetings. Workshops, delivering presentations or training, and explaining the results of my research.

But the worst are days where I have an hour’s meeting followed by an hour “gap,” repeated. Technically, I’m only in meetings for half the time, but it wipes out the whole day in terms of productivity. I spend half the day either context switching or with a tranche of time that’s too small to do much useful. A few days of these meetings and I feel very busy but not very productive.

The internet is full of suggestions on how to manage your schedule correctly. Few of them work for me.

A popular suggestion is to schedule meetings together, always in the morning or late in the day, for example. But what if I have clients in India and colleagues in the US? (I do.) There can be meetings at any time, and timezones mean that I can’t reasonably move them. I do have a certain amount of latitude in terms of moving some meetings around, but there are constraints beyond my productivity. If I (an individual) am trying to set up a workshop with half-a-dozen people and they’re paying for the privilege of meeting me, I’m at a disadvantage, schedule-wise.

Another suggestion is to block out the time in my calendar. This is probably the most effective method, but it’s not without its challenges. It’s hard to ‘hold the line’ against people booking meetings. Whether it’s someone not knowing how to check your calendar (or them not caring), frequently pushing back when you have no other firm commitments can look like you’re not a “team player.”

Another reason it’s hard to keep those time blocks is that it can be hard to know how long they need to be. Consultants usually have to maximise “billable time,” which makes it hard to turn down sure-fire client-facing hours. If I block out four hours in my diary, what’s to say I won’t get stuck after an hour and have to wait for feedback? What do I then do with the remaining three hours? It’s a real optimisation and opportunity cost problem.

So what’s the answer? I wish I had the One True Way. I’m not sure that one exists. Unlike many of the other people giving advice on the internet2, I am not 100% in control of my schedule. The best I’ve been able to come up with is a combination of all of the above. I try to have meeting-free days. I try to block time where it makes sense.

To an extent, it’s my job to be flexible and available for clients. Maybe I just need to learn to live with it?

  1. I’m a “field engineer”, which means I help clients get the most out of my company’s software. ↩︎
  2. As ever, you get what you pay for. ↩︎
Blog

The Art of Leadership

Before you ask, yes, it is weird that I’m reading a bunch of “management” books.

You can watch Michael Lopp’s career by following his various books. Start with “Being Geek,” the software developer’s career handbook. The move into management resulted in “Managing Humans.” And his promotion from manager to director and executive gets you “The Art of Leadership,” which is the book I recently finished.

My career has not followed the same trajectory. I continue to be an “individual contributor,” so why would I read this book?

Two basic reasons. First, Lopp is a great writer. He wraps the lessons around relatable stories, even if they don’t exactly mirror my experience. Secondly, to use a cliché, leadership comes from everywhere. I may not manage people, but I do have to lead. As a consultant, my whole job involves influence, persuasion and strategy.

In short, I don’t think you have to be a manager to get something out of this book, but if you like to sit in the corner and code all day, it’s unlikely to be your thing.

The book is structured into three sections, manager, director and then executive. Within each section, there are a bunch of small things that, done well, will result in great results (hence the sub-title). There are so many great parts that it would be easy to quote the whole book. I’ll refrain, but here are a few highlights and observations.

There are parallels with other books I’ve read recently. Chapter 15 “Saying the hard thing,” covers a lot of the same ground as “Radical Candor,” with many of the same positives.

The “faux zone” is very relatable. There are certainly times when I feel incredibly busy, but at the end of the day, I don’t feel like I got anything done. There are insights here that make me feel better about it.

A “Precious Hour” reminds us that being busy is not the same as being productive.

And, finally, this is so me: “I love to start new things, but I often lose interest when I can mentally see how the thing is going to finish, which might be weeks or months before the thing is actually done. Sorry. I’m getting better at this.” I remember I did one of those “type indicator” tests a long time ago, and one of the categories was “completer-finisher.” I immediately knew that I was the opposite of that.

As with all books like this, some of the suggestions I already do while others are not relevant; however, taken as a whole, there’s plenty of good advice.

Blog

Radical Candor

“Radical Candor” is one of those phrases that I’ve heard and wondered about. Is it another vacuous management phrase? Does it mean anything? I saw it in the library and thought I’d find out. I’m cynical about these things but it doesn’t mean I’m closed minded!

The pitch is “Be a kick-ass boss without losing your humanity” which sounds positive but I don’t manage people at work. Even if it contained genuine insight, would there be anything I could use?

The book starts with a description of what “Radical Candor1” is and finishes with how to apply the theory, an approach that I prefer to “How To Win Friends and Influence People” where the story is scattered throughout the text.

The examples vary in how useful or relatable they are. Some I was nodding with recognition. Others were some way out of my experience.

There’s an example early on where the author says “Um” too much in a meeting and her boss immediately offers a speech coach.

How many people get that experience?

I’ve never been offered a coach, not even when my failings have been much more significant than the occasional “Umm”! Have I been working for the wrong companies or have I been in the wrong jobs?

I guess the idea is that if someone who name-drops half of Silicon Valley can use “Radical Candor,” then so can you.

But much of the rest of the book did work for me. The idea of building trust and then providing rapid, honest feedback seems (self evidently?) like a good thing. I could imagine past conversations where I could apply the advice. I understood some cases where I’d done a good job; others where I’d missed.

I don’t think you need to be in a management position for this book to be useful. Anyone in a job where there’s an element of leadership might get something from it.

Do you need to go on a training course or read the full book to get the gist? Unlikely. But is there some value here? Absolutely.

  1. I’m going to use the American spelling as that’s the name of the book, but I can’t say I’m happy about it. ↩︎
Blog

Cloud Without Compromise

A couple of years ago I did a conference talk called “On Cloud Nine: How to be happy migrating your in-memory computing platform to the cloud.” I wish I’d had “Cloud Without Compromise” back then. It covers much of the same ground but, as you’d expect in a book rather than a forty minute conference talk, in much greater depth. More importantly, it puts some concepts into context much more clearly that I did, either by explaining it better or by giving it a good name.

One of the main takeaways of the book, something that is mentioned throughout, is the mantra “Cloud is a capability rather than a destination.” In my talk I hint strongly at that but never made it explicit. I always felt that “the cloud is just somebody else’s computer” didn’t fully encapsulate the magnitude of change but wasn’t able to articulate it concisely. Well, here’s the line to use.

This book took a long time to read. Not because it’s badly written or exceptionally long but because every few paragraphs I had had to stop and think about the implications, how the subject applied to my recent work or research a new tool that I had not come across previously.

There have not been many technical books I’ve read recently that have had this impact. Naturally not everything was new to me, but even then rephrasing a concept or putting it into context can be immensely useful.

It is also very approachable. There’s a nice appendix on some of the more technical aspects, there are some nice anecdotes and even a little humour.

“You’re the most unromantic person I know.”

If there’s a criticism, it’s that some parts read as an advertisement for IBM and RedHat. The last chapter in particular, which is about automation, could be a White Paper for Ansible. Sure, the focus of the book is on hybrid cloud, where the other big vendors are pushing their own agenda, but the OpenShift advocacy would be less signifiant were it not for the fact that a couple of the authors work for IBM. On the one hand you have to write what you know. On the other, shilling your employers products in what’s supposed to be a vendor neutral book sits awkwardly.

For what it’s worth, the advice does not appear to be incorrect but I wish there had been more discussion about competing products or they’d stayed clear of talking specifics at all.

Overall, though, “Cloud Without Compromise” comes highly recommended.

Blog

Reading 2021

I failed to reach my target of reading twelve books in 2021 by quite some margin this year. I finished only ten books, and that’s including the cheat of counting two short stories as two books!

Despite my objective of reading more fiction, I also failed with that (just the one novel and the two short stories).

While the volume was down both on previous years and my target, the quality was actually pretty good. From the story of the company behind the BlackBerry to the story of the Seventies, how to build a computer and how computers were made. All were worth a read.

The low-light was undoubtedly Malcom Gladwell’s “Talking to Strangers.” A reasonable “long read” blog post but stretched very thin over an entire book.

For 2022 I have the same target as 2021. Will I do better this time? Watch this space…

Talking of which, what is the point of these posts? Are they reviews? Not really, they’re thoughts or recollections or highlights of reading the books. Some read more like reviews, others are tangents, things that reading the book made me think about or consider in a new light.