The Problem With “John”: The Developer Who Built Everything but Documented Nothing
by Arif Ikhsanudin, Backend Developer
Every team has a “John”—the brilliant developer whose output seems unstoppable.
Features roll out, production stays stable, and managers see him as indispensable.
But there’s a hidden cost: the rest of the team struggles to understand, modify, or safely extend his code.
Code Should Be Living Documentation
Documentation isn’t just a separate Word file or PDF.
- Well-written code explains itself in clear naming, structure, and comments
- High-level architecture embedded in the code helps others understand design decisions
- Tests, examples, and readable functions are part of “living documentation”
When John writes code that only he can decipher, the system becomes a trap rather than a guide.
The Paradox of Perceived Value
Because John produces so much, he looks good in the manager’s eyes.
- rapid delivery impresses stakeholders
- managers may overlook maintainability issues
- “John is busy, don’t disturb him” becomes team lore
Meanwhile, other developers hesitate to touch his codebase—any mistake feels high-risk.
Invisible Bottlenecks
John unintentionally creates obstacles for team productivity.
- peer developers avoid areas of the code he owns
- onboarding new hires becomes painful and slow
- dependencies and tight coupling make seemingly simple changes risky
What appears as heroism to outsiders is a hidden drag on velocity for the team.
Encouraging a Culture of Readable, Maintainable Code
Teams can mitigate these issues without stifling creativity.
- enforce clear naming conventions and code readability
- encourage self-explaining functions and thoughtful structure
- code reviews and pair programming distribute knowledge, not hero worship
The goal is living documentation that communicates through the code itself, not through extra files.
Balancing Individual Brilliance and Team Flow
John’s contributions are valuable—but only if they help the team, not just impress managers.
- celebrate output while prioritizing clarity and maintainability
- teach that code is communication, not a personal trophy
- empower others to safely work on any part of the system
Brilliance that isolates is fragile; brilliance that educates is sustainable.
John may deliver miracles, but the real measure of a team’s health is whether everyone can safely build on each other’s work.
Code should speak in plain English, not just to the genius who wrote it.