In an ideal work environment, developers should be able to work at a sustainable pace, do quality work, and feel secure in their roles. But when those conditions break down—when pressure to deliver mounts or job security feels uncertain, some developers may turn to defensive strategies.
One such strategy is to make themselves appear indispensable, not by creating exceptional value, but by increasing the cost of their absence. This can manifest as writing overly complex or undocumented code that relies heavily on personal knowledge. In extreme cases, the system becomes so entangled with the developer’s mental model that no one else can effectively maintain or modify it. Firing or reassigning them becomes risky, as the business is now dependent on a single point of failure.
This creates a toxic incentive structure: instead of building maintainable, transparent systems, developers might (consciously or not) optimize for obscurity. The less accessible their work is to others, the more secure their position seems. It’s a subtle shift from collaboration to control, from engineering to gatekeeping.
The result is a fragile codebase and a bottlenecked team. Progress slows, onboarding becomes painful, and the organization becomes vulnerable not because the work is uniquely brilliant, but because it was deliberately made opaque. In this way, technical complexity becomes a kind of internal politics, used not to solve hard problems, but to protect status within the company.
If your company creates an environment where people feel like they might be fired for underperforming or where stress is constantly high, that culture itself becomes a breeding ground for these problems. When developers are more concerned with self-preservation than collaboration, code quality suffers. And eventually, when that one “indispensable” person leaves, the entire system they built can fall apart. It’s not enough to focus on technical processes you must address the emotional and cultural conditions that lead people to write defensive code in the first place.
To guard against this dynamic, companies should adopt proactive measures that encourage clarity and accountability in code. One effective approach is to regularly have junior developers read and work with code written by senior engineers. If junior team members struggle to understand the code or require excessive time to become productive with it, that’s a strong signal that something is wrong—not with the juniors, but with the code itself.
Code written by senior developers should set the standard for maintainability, not act as a barrier to entry. If it’s inscrutable to new team members, it may be suffering from the very issues described above: over-complexity, lack of documentation, and excessive reliance on private context. In these cases, leadership should take a closer look—not just at the code, but at the practices and incentives that allowed such opacity to take root.