Formative Ideas

This page contains links to articles that have had a major impact on my approach to leadership in software engineering. They're all worth a read.

My Approach to Building Large Technical Projects -- Mitchell Hashimoto

Mitchell Hashimoto has a bit of experience building large technical projects, having co-founded HashiCorp. What's most notable about this article is that he doesn't come off as super-human. Rather, he seems to be excellent at defining and reaching the next small milestone, which feels like a much more attainable goal.

Instead, I try to think what a realistic project is where I can see results as soon as possible. Once you apply that filter, the number of viable sub-projects shrinks dramatically.

Magnitudes of Exploration -- Will Larson

The key idea in Magnitudes of Exploration is to lean into the technologies you know until something comes along that demonstrates a clear order-of magnitude-improvement over what you're currently using. In my experience, people diminish the switching cost of moving from one language/framework/tool to another. What's more, the comfort and efficiency gained by sticking with a particular technology pays dividends over time. New projects come together faster. Documentation crops up for common issues. Engineers build automation for cumbersome manual tasks. The list goes on. Will puts it this way:

Standardization is so powerful that we should default to consolidating on few platforms, and invest heavily into their success. However, we should pursue explorations that offers at least one order of magnitude improvement over the existing technology.

This improvement shouldn’t improve on a single dimension with meaningful regressions across other aspects, but instead it should approximately as strong on all dimensions and at least one dimension must show at least one order of magnitude improvement.

When a technology passes this threshold, its benefits will heavily outweigh the benefits of standardization. Until that point, it's worthwhile to avoid flavor-of-the-month and invest in what you know.

Shape Up -- Ryan Singer

There's a lot to unpack in Shape Up. Its primary purpose is to describe the planning process at 37signals, which, while very opinionated, contains a lot of thought-provoking ideas even if one doesn't adopt the process wholesale.

The book is very helpful in outlining what the act of productive planning looks like. It's easy for new team leads to spend time on things that seem like work while accidentally neglecting tasks that actually give the team focus and direction. In this model, design docs are the core output of planning. Once an idea is refined to the point of being a solid design document, it can be assigned to teams of engineers.

In my experience, focusing primarily on design docs has a number of benefits. First, the act of writing always shows where one's thought process has an unexpected gap, and anything that can surface gaps before implementation is valuable. Second, it gives engineers a framework and context in which they can make good individual decisions rather than spinning their wheels on large, open-ended questions. Third, it helps to disassociate the idea with any individual person's ego. When people give feedback on the document, they're working to improve the idea that's being described rather than arguing with the person who is pitching it.

Shape Up, itself, is about quite a bit more than just writing design docs. However, it has really helped me to better understand how to take abstract ideas and refine them into something that looks a lot more like a plan and a lot less like a hope or an aspiration.

Algorithms We Develop Software By -- Grant Slatton

This short article has two stand-out ideas for me. "Write everything twice" and the "gun to the head heuristic". Since the article is so short, it's better to go ahead and read it than attempt to summarize here.