Aug 01, 2025

Recently I had a conversation with a high-rank manager who didn’t see value in code ownership. He talked about design and ideas, but not people and tasks. This reminded me how past breakages were caused by people making changes without sufficient context. Or how a new team member spends a week on a task that takes twenty minutes. I’d like to split this context into three parts:

1. System design - the pretty diagramming part, that is usually done well, covered in design docs and presentations. A good design, though, is so boring, that you can grasp the idea in ten minutes.

2. Core principles - the ideas that influence how the design was produced. This is surprisingly variable between teams, never documented, and lives between an architect’s head and tribe knowledge. It’s also fluent, has many interpretations, and can be hardly expressed in words.

3. Minute decision that are seldomly discussed but spread all over the code. This is the biggest chunk of the context, the meat and cause of all the quirks and optimizations.

Of all three, only the first one is available to people outside of the code owners. The other two take so much effort to maintain, that only the owners have the capacity to hold.