Behind every code review fight are two engineers remembering different disasters.
Two engineers are arguing over a pull request. One wants the data schema defined, typed and reviewed before any code is written against it. The other wants to ship the feature, see how the data actually gets used, and let the schema follow. Both are competent, and each finds the other faintly unreasonable. Next month the argument will return with a different pull request. Why don’t arguments like this ever settle?
Steve Yegge’s answer is that software engineering has its own political axis, running from conservative to liberal. It has nothing to do with real-world politics. It is about risk management, and the question underneath every position on it is how much focus you should put on safety.
Two value systems
The conservative engineer is motivated by the psychological management of uncertainty and fear. Safety trumps other considerations: software should be bug-free before launch, production code statically checked, data stores rigidly schematized, and any doubt about a component’s safety keeps it out of production. The schema-first engineer is a conservative.
The liberal engineer wants to maximize speed of development and flexibility of systems. Bugs happen anyway, so good debugging beats prevention. Schemas should follow code, because a rigid schema is a guess about how the interface will evolve. Companies must take risks or die. Programmers are only newbies briefly, and optimizing for the transient case (new hires) instead of the steady state (competent engineers) is a fundamental category error.
Both believe they are optimizing for working software, but their priorities clash at every stage from design to recovery, so each new decision reopens the fight.
Why neither side moves
Each camp’s position rests on formative experience. The conservative was on a team where a cowboy coder shipped a bug that cost millions, so safety is non-negotiable. The liberal was on a team where the safety bureaucracy prevented shipping for two years, so speed is survival. Both are generalizing from real damage, and neither is wrong about the failure they lived through. Each is wrong about the failure they haven’t lived through, which is exactly the one the other camp is trying to prevent.
That is why argument rarely moves anyone. Telling the schema-first engineer about the cost of delay sounds like telling her the outage she spent a weekend cleaning up didn’t matter.
Context, not identity
The way out is to read the axis as risk appetite, which should depend on the system rather than the engineer. A pacemaker should be conservative. A startup MVP should be liberal. A mature platform should be conservative at the core and liberal at the edges. Effective teams often run a liberal core inside conservative guardrails such as monitoring and automated rollback. Those guardrails are recovery infrastructure that makes risk-taking rational rather than reckless, and they give both engineers something they want.
The mistake is making your position on the axis into an identity rather than a tool. The moment you say “I am a conservative programmer” rather than “this system needs conservative treatment,” a design decision has become a tribal allegiance, and contempt follows. The expert beginner shows the end state: once safety is identity, any push toward flexibility reads as an attack.
Recognizing the axis does not resolve the disagreement, because the underlying values genuinely conflict. What it changes is the conversation. Instead of trying to persuade each other, the two engineers can ask what this system’s failure would cost and how quickly they could recover, and negotiate from there. The open question is whether either can answer without consulting their scars.
References:
- Steve Yegge, Notes from the Mystery Machine Bus (also known as “Liberal vs Conservative Programmers”)