An Elegant Puzzle: Systems of Engineering Management

It's interesting to learn from Larson's experience as an engineer and manager. In this book, he covers a great deal about managing software, including sizing engineering teams, managing technical debt, fostering communities of learning, and systems thinking. I'd recommend this book to any software engineer or manager.'

Finally, the one thing that I’ve found at companies with very few interruptions and have observed almost nowhere else: really great, consistently available documentation. It’s probably even harder to bootstrap documentation into a non-documenting company than it is to bootstrap unit tests into a non-testing company, but the best solution to frequent interruptions I’ve seen is a culture of documentation, documentation reading, and a documentation search that actually works.

Most system-implemented systems are designed to support one to two orders magnitude of growth from the current load. Even systems designed for more growth tend to run into limitations within one to two orders of magnitude. If your traffic doubles every six months, then your load increases an order of magnitude every 18 months. (And sometimes new features or products cause load to increase much more quickly.) The cardinality of supported systems increases over time as you add teams, and as "trivial" systems go from unsupported afterthoughts to focal points for entire teams as the systems reach scaling plateaus (things like Apache Kafka, mail delivery, Redis, etc.).

Instead of asking the candidate to explain some architecture on the spur of the moment, give them a warning before the interview that you'll ask them to talk about a given topic for 30 minutes, which is a closer approximation of what they'd be doing on the job. Debugging or extending an existing codebase on a laptop (ideally on their laptop). This is much more akin to the day-to-day work of development than writing an algorithm on the board. A great problem can involve algorithmic components without coming across as a pointless algorithmic question. (One company I spoke with had me implement a full-stack auto-suggest feature for a search inbox, which required implementing a prefix tree, but the interviewer avoided framing it as yet another algo question.)

Have you ever worked at a company where the same two people always got the most important projects? Me too. It's frustrating to watch these opportunities to learn from the sidelines, and reliance on a small group can easily limit a company's throughput as it grows. This is so important that I’ve come to believe that having a wide cohort of coworkers who lead critical projects is one of the most important signifiers of good organizational health.