Energy Management

I recently read The Engineering Leader by Cate Huston, a former senior lead at Automattic. The book covers many aspects of engineering leadership and highlights that being a lead means doing most of those things—like holding 1-on-1s, knowing what to discuss in them, hiring well, and onboarding people effectively so they integrate into the team instead of heading straight for the exit, but also providing feedback, managing performance and so on.

There’s one idea in the book that especially resonated with me, and I think it’s worth exploring further: the recognition that doing both lead work and programming work isn’t just about time management. It’s about energy management.

Take programming, for example. I might get a task like: rework this flow so it now handles five new behaviors. That kind of work flows roughly like this: I check the code, break the work into five tasks plus another five hidden requirements, estimate the total effort, and start closing the issues one by one. We end up completing 12 things, dropping a couple of the original five, and calling the project done. This is mostly a function of time spent, with just a few moments requiring deeper mental effort—typically at the beginning (when figuring out where to start or syncing with stakeholders) and the end (when shipping and hoping nothing breaks).

But then there’s another kind of work: writing a post-mortem for something I broke. Giving feedback to a direct report. Auditing a past project and writing up the results. Clarifying project requirements with external stakeholders. These tasks aren’t necessarily time-consuming, but they’re mentally expensive. They’re ambiguous, emotionally uncomfortable, and often easy to avoid. Stack three of them in a single day and you might get nothing else done—or feel like you can’t do anything at all. And if you don’t do them, the next day will be the same.

Cate Huston puts a name to this: mental energy. For me, just acknowledging that this is a major constraint in leadership work is the biggest takeaway from the book.

Looking back, I had already developed some coping strategies without realizing I was solving an energy problem:

  • I schedule draining tasks directly into my calendar. This includes not just work tasks, but things like dentist appointments—or even just scheduling the dentist.
  • I’ve learned which personal conversation topics tend to drain me, and I try not to explore those too deeply.
  • Quick but draining tasks get done first thing in the morning.
  • A task that’s so unpleasant it puts me “in the red” gets prioritized—because while I’m in that state, I can’t reasonably do much of anything else.
  • I break difficult tasks into smaller, more approachable chunks, and just tackle one at a time.

However, now that I know this is actually science, I can explore it further and see where can this get me.

Cate Huston raises plenty of other interesting topics in the book, and overall, I think it’s a worthwhile read.

The Single Cockroach Rule

Seeing one cockroach under the sink usually means an infestation. Roaches like to hide. It only showed up because the hiding spots were overcrowded.

I like to apply this generalization to software engineering—especially over beer.

  • If you receive a single bug report about a feature you just launched, it likely means the feature is completely broken. Users tend to work around UX issues and only reach out to support when things are really bad and they have no other options.
  • That one security, usability, or other issue you noticed in a pull request? If there’s one in the PR, there are probably more in the adjacent code.
  • A missing space in a code change? That usually means there’s no linting in place.
  • A missed edge case? It might indicate something is off in our testing process.

The way I defined this Cocroach Rule matches the definition of a Hasty Generalization. After all, one cockroach—or one bug—is a sample size of one. There’s always a chance that a reported issue is an extreme outlier, something no one else will ever encounter. Maybe a high-energy particle hit a chip somewhere. It happens.

But my long-term experience shows that the Single Cockroach Problem largely holds true. It applies in many areas where the difference between zero and one is significant.

How hiring people motivated me to grow

Daily writing prompt
Describe a decision you made in the past that helped you learn or grow.

In the early 2000s, I was a new and ambitious software engineer with very little theoretical knowledge. Worked as a webmaster, which included front-end, back-end, databases, and a bit of systems work, all with Microsoft products. My confidence didn’t match the realities of my actual knowledge. Something happened and 2-3 colleagues quit in the same year, leaving me as the most senior developer, despite my young age and limited knowledge. I had to hire replacements. So, I found some article that said that I should only hire people who are better developers than me. It said that “A people hire A people, B people hire C people” (attributed to Steve Jobs). I took that meme very seriously. The folks I hired were so good that I needed to step up my game significantly to remain relevant. In the process of learning, I decided to go back to the university and get a Master’s degree in Information Systems from Sofia University.

I’ve done some hiring work later and found loopholes in this rule (so did others on Hackernews). Looking for people who are significantly more competent than the hirer opens the gates to masters in BS language (link to a post from January on the subject). If I discuss an area where I’m not particularly knowledgeable with a candidate, the candidate could fool me by using impenetrable language, specific to that technology.

Over time, I changed. I currently believe that:

  • The ability to explain past work would be a top skill during a hiring interview, closely followed by soft skills
  • Every single person on the planet would be better than me at something and I’m just a few questions away from figuring out what that thing is

Despite that, I did hire some good folks, and they motivated me to learn and improve. Maybe not the most impactful choice I made in life but quite good.