Git Worktrees Are Scratch Lanes for Coding Agents
Git worktrees help AI coding by isolating agent experiments, not by pretending the hard part of integration disappeared.
Edsger Dijkstra: Why Discipline Beats Cleverness
6 min read
He Treated Sloppiness as a Design Failure
26.06.2026, By Stephan Schwab
Software culture still rewards the flashy trick, the heroic late-night save, and the developer who can untangle a mess nobody else understands. Edsger W. Dijkstra spent decades attacking that posture as professional self-deception. He argued that software improves when we remove unnecessary cleverness, reason about correctness before we ship, and stop treating confusion as proof of brilliance. That sounds severe right up to the moment you inherit a brittle system held together by folklore.
The Offense Was Not Bugs. It Was Carelessness.
"Dijkstra was not impressed by code that merely worked. He wanted code that deserved to exist."
Edsger W. Dijkstra is often remembered for an algorithm, a famous letter about goto, and a reputation for being intolerant of sloppy thinking. The reputation was earned.
Born in Rotterdam in 1930, he became the Netherlands’ first official programmer in 1952 at the Mathematical Centre in Amsterdam. He later worked at Eindhoven, Burroughs, and the University of Texas at Austin. Along the way he gave us the shortest path algorithm, seminal work on semaphores and operating systems, and a body of essays sharp enough to make half the profession defensive on contact.
He had little patience for the habit, still common in software, of celebrating whatever passes the demo and postponing the hard questions until production starts screaming. For Dijkstra, the central problem was not that programs sometimes contained bugs. The deeper problem was that developers accepted muddle as normal.
That is why his writing still lands so hard. He did not talk like a framework salesman or a process consultant. He wrote like someone who had seen what happens when complexity grows faster than understanding. Then he refused to flatter the people causing it.
Structured Programming Was a Revolt Against Chaos
"The point of structured programming was never style. It was to make reasoning possible before the damage was live."
In the 1960s, large programs were becoming tangled masses of jumps, flags, hidden state, and control flow that only their original authors could follow. The machine executed them. Humans suffered them.
Dijkstra’s 1968 letter “Go To Statement Considered Harmful” became the public symbol of a broader movement, while the underlying argument is already visible in his earlier essay A Case against the GO TO Statement. The slogan was simplified into a syntactic food fight, as these things usually are. The real argument was more serious. If control flow can jump anywhere, reasoning about a program becomes far harder than it needs to be. And if reasoning becomes hard, quality becomes theater.
Structured programming was not about purity for its own sake. It was about creating code whose behavior could be understood locally, composed safely, and checked with discipline. Sequence, selection, iteration, clear boundaries, explicit invariants. Not because those ideas feel tidy, but because they reduce the space in which software can lie to you.
You can hear the same argument today whenever a team tries to tame an overgrown codebase. Replace spooky action with explicit ownership. Remove hidden coupling. Shrink functions until they say one thing clearly. Stop congratulating the person who “just knows” how the mess works.
Correctness Begins Before the Test Run
"Program testing can be used very effectively to show the presence of bugs, but never to show their absence."
- Edsger W. Dijkstra, On the reliability of programs
- Edsger W. Dijkstra, On the reliability of programs
Dijkstra’s line about testing gets quoted constantly and understood shallowly. He was not dismissing tests. He was warning against magical thinking.
A test suite is evidence. Good evidence, sometimes excellent evidence. It is not absolution. If the underlying design is incoherent, if responsibilities are smeared across layers, if business rules are duplicated in six places with slightly different wording, then a wall of green checks may only prove that the confusion has not reached the sampled edge cases yet.
That insight fits modern software painfully well. Plenty of teams talk about quality while leaving the system structurally unfit for reasoning. They pile up end-to-end tests, approval steps, and pull-request rituals because they do not trust the shape of the code. The rituals are compensating for design debt.
Dijkstra kept pushing the responsibility earlier. Think before coding. State assumptions. Make the control flow legible. Keep the mental model small enough that correctness is discussable rather than mystical.
His Algorithm Was Famous. His Standard Was Higher.
"The shortest path algorithm made him famous. His real contribution was treating clarity as a technical requirement."
Yes, Dijkstra gave us the shortest path algorithm every computer science student meets sooner or later. Yes, he worked on semaphores, mutual exclusion, deadlock avoidance, self-stabilizing systems, and foundational ideas across programming languages and distributed computing. The résumé is absurd.
But software development did not most need another genius who could solve a hard mathematical problem. It needed someone willing to insist that ordinary programming should stop being a swamp of clever exceptions and improvised escapes.
That is why he kept hammering on elegance, simplicity, and discipline. Not as aesthetic luxuries. As operational necessities. Complex systems already contain enough unavoidable difficulty. Adding avoidable confusion on top is professional negligence with better branding.
The Cult of the Hero Developer Would Have Annoyed Him
"If one person has to stay indispensable so the system keeps running, the system is already misdesigned."
A great deal of modern software folklore still revolves around the heroic developer. The one who remembers the hidden switch. The one who can patch production at 2 a.m. The one who alone understands the billing engine, the deployment pipeline, or the cursed integration nobody dares touch.
Dijkstra would have looked at that and diagnosed a management and design failure, not greatness.
Software should not depend on mystique. It should not require ritual initiation. If understanding the system depends on tribal memory and fragile prestige, then the organization has built a status game around opacity.
That is also why his work matters far beyond syntax debates. He was arguing for a professional culture in which developers reduce accidental complexity instead of turning it into personal leverage. The payoff is not only technical quality. It is organizational sanity.
What Dijkstra Still Teaches Us
"Simplicity is not the opposite of sophistication. It is what sophisticated people fight for when they understand the cost of chaos."
Dijkstra’s message survives because software keeps recreating the conditions that made him furious.
We still glorify cleverness when clarity would serve better.
We still let architecture sprawl until teams need ceremonies to coordinate around avoidable confusion.
We still confuse post hoc testing with disciplined design.
We still reward the keeper of the maze more than the person who removes a wall.
The lasting lesson is not that every program should look mathematically pristine. Real systems are messier than manifestos. The lesson is that software gets better when we treat understandability as a hard constraint. Clarity is not decoration. It is a precondition for correctness, collaboration, and long-term speed.
Dijkstra did not ask developers to be less ambitious. He asked them to stop being impressed by the wrong things.
References
Dijkstra disliked bibliographies. This one is for the rest of us.
- Edsger W. Dijkstra Archive, University of Texas at Austin
- A Case against the GO TO Statement (EWD215)
- On the reliability of programs (EWD303)
- ACM Turing Award citation for Edsger W. Dijkstra
- Biographical overview: Edsger W. Dijkstra on MacTutor
Contact
Let's talk about your real situation. Want to accelerate delivery, remove technical blockers, or validate whether an idea deserves more investment? I listen to your context and give 1-2 practical recommendations. No pitch, no obligation. Confidential and direct.
Need help? Practical advice, no pitch.
Let's Work Together🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
The Cost of Speed
As Q3 kicks off, the pressure to deliver the tournament system mounts. Anton pushes for a fast-and-dirty implementation of the matchmaking UI, argu...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Git Worktrees Are Scratch Lanes for Coding Agents (25.06.2026)
- OpenClaw and Nilo Assistant: What Each One Is and Is Not (22.06.2026)
- AI Won't Refactor Your Web Component (19.06.2026)
- Talent Shortage or Filter Failure? (15.06.2026)
- Stop Arguing From Memory About Code (12.06.2026)