Thought: Use Documentation for Knowledge Building.
People often assume that code is knowledge. They want “self explanatory” or “well documented code”. Companies and managers often treat developers as interchangeable. But therein lies the mistake.
Knowledge exists in mental models and team structures. Small components and systems can be understood by a person, but team structure also embodies knowledge of larger systems. People will need complementary mental models to understand a large system together.
That’s why adding manpower to a late project makes it later. That’s why maintenance is hard and handover is harder. That’s why systems devolve into big balls of mud. Because companies and managers do not respect the fact that you need people and teams who have good mental models and that mental models take time to build and share.
No amount or quality of code can make up for this fact. And simulacra of ownership - having “product owners” or whatever - won’t cut it. You need people to own their systems, understand them deeply. Moving people around, churn, treating developers as interchangeable, substituting rituals for deep work, accumulating ‘technical debt’ (deferred work as in ship now and think later) etc are all detrimental to building and sharing sound mental models.
There’s no replacement for knowledge and sound mental models. Documentation, tests, they can help but they cannot replace having a knowledgeable person around.
Simplicity leads to success
The more things software can do, the harder it is to reason about what it’s supposed to do
Purposeful simplicity is harder than accidental complexity.