Introduction

Edsger W. Dijkstra (1930–2002) is undoubtedly one of the most influential pioneers of modern computer science. Creator of the shortest path algorithm, inventor of semaphores, and opponent of abusive complexity, he shaped our way of thinking about code and program theory. As a software engineer, I find myself deeply resonating with his relentless pursuit of clarity: learning to transform abstract ideas into lucid artifacts, where every line of code bears an irrefutable mathematical justification. My point is simple: Dijkstra was not just an outstanding engineer, but a philosopher of computer science, for whom rigor and simplicity constituted a form of intellectual asceticism. Through this essay, I will examine his career and thought, analyze his vision of simplicity as a demand, and draw practical lessons for the contemporary software engineer.

I. Dijkstra, Engineer and Philosopher of Computer Science

A. An Extraordinary Scientist

Born in the Netherlands, Dijkstra earned his PhD in applied mathematics from Eindhoven University before joining Philips laboratories. Very quickly, his shortest path algorithm revolutionized not only graph theory but also found concrete applications in networks, logistics, and planning. At the same time, he formalized the concept of the semaphore, a cornerstone of concurrent programming, and contributed to the definition of ALGOL, one of the first structured languages. His influence then extended from Europe to America, where he served at the University of Austin (Texas), training a generation of researchers to think of computer science as a rigorous and disciplined science.

B. A Critical and Unconventional Thinker

Far from the limelight, Dijkstra distrusted trends: he did not use email and denounced the illusion of productivity fostered by ubiquitous graphical interfaces. His approximately 1,300 EWD (Edsger W. Dijkstra) reports are not mere technical documents, but true intellectual manifestos, where his wit, biting humor, and critical rigor are expressed. In “On the Cruelty of Really Teaching Computing Science”, he warns against empirical learning based on trial and error and advocates for an approach centered on proof and formal demonstration.

II. Simplicity as an Intellectual Demand

A. The Maxim: “If Your Proof Exceeds Five Lines, You Made It Too Complicated”

Dijkstra often criticized lengthy or convoluted proofs, for him, clarity was a moral imperative in scientific thought. This injunction is not a stylistic whim, but the expression of a mathematical ideal where each step must be absolutely necessary and immediately understandable. In his view, the clarity of the argument is inseparable from its truth: the more concise a proof, the more it reveals the fundamental structure of the problem.

B. Against Accidental Complexity

He clearly distinguished essential complexity, inherent to the problem to be solved, from accidental complexity, the result of clumsy design or inappropriate tools. He condemned the “over-engineering” of architectures piling on layers and hollow abstractions, as well as “magical” frameworks that generate opaque, hard-to-maintain code. His message is clear: every dependency, every line of code must justify its presence by a gain in understanding or robustness.

C. Simplicity and Truth: An Intellectual Asceticism

Like classical mathematicians – Euclid, Leibniz, or Pascal – Dijkstra saw simplicity not as ease, but as the effort of refinement. Writing less to say more requires intense intellectual labor: identifying invariants, isolating the core of the problem, rejecting the superfluous. This asceticism is not dogmatic; its strength lies in the conviction that algorithmic beauty arises from conceptual purity.

III. A Lesson for the Modern Software Engineer

A. Rethinking Computer Science Education

Dijkstra condemns “debugging-oriented programming,” where learning is limited to fixing errors as they arise. He advocates for teaching program proofs, abstract thinking, and formal modeling from the earliest years. By making verification a reflex, we avoid the proliferation of costly bugs and develop a coherent vision of systems.

B. Engineering as the Art of Proof

According to him, a good programmer is first and foremost a logician. Functional programming, with its pure functions and invariants, embodies this rigor. The use of types, pre- and postconditions, or even proofs by induction, allows for the construction of software whose behavior is guaranteed. Refusing the compromises of technical debt is to side with solid, scalable, and understandable code.

C. What I Personally Take Away

On a daily basis, Dijkstra’s ideas guide my practice: I seek variable names that express intention, I write tests as small formal proofs, I avoid overly generic abstractions and favor minimalist APIs. I reject flattering complexity – those exotic patterns meant to showcase my skill – and aim for solutions that, once exposed, seem “obvious in hindsight.” Behind this immediacy, there is always a long work of reflection and refinement.

Conclusion

Edsger W. Dijkstra leaves behind an invaluable intellectual and practical legacy. His philosophy, founded on rigor, clarity, and ascetic simplicity, constitutes a salutary antidote to the proliferation of opaque and hypertrophied computer systems (greetings to the JS ecosystem). More than ever, in a world governed by obscure algorithms, his message reminds us that algorithmic beauty lies in conceptual purity. And if simplicity is a demanding ideal, it is also an ethical commitment: to make technology understandable, reliable, and ultimately, worthy of everyone’s trust.