What do you think?
Rate this book
EWD 340: The Humble Programmer
This is the transcript of the ACM Turing Award Lecture delivered by Edsger W. Dijkstra in 1972.
15 pages, ebook
Published January 1, 1972
4 people are currently reading
205 people want to read
About the author
Edsger W. Dijkstra
15 books142 followersEdsger Wybe Dijkstra was a computer scientist. He received the 1972 Turing Award for fundamental contributions to developing programming languages, and was the Schlumberger Centennial Chair of Computer Sciences at The University of Texas at Austin from 1984 until 2000.
Shortly before his death in 2002, he received the ACM PODC Influential Paper Award in distributed computing for his work on self-stabilization of program computation. This annual award was renamed the Dijkstra Prize the following year, in his honor.
His influential 1968 paper "A Case against the GO TO Statement", later published by Niklaus Wirth with the title "Go To Statement Considered Harmful", introduced the phrase "considered harmful" into computing.
Shortly before his death in 2002, he received the ACM PODC Influential Paper Award in distributed computing for his work on self-stabilization of program computation. This annual award was renamed the Dijkstra Prize the following year, in his honor.
His influential 1968 paper "A Case against the GO TO Statement", later published by Niklaus Wirth with the title "Go To Statement Considered Harmful", introduced the phrase "considered harmful" into computing.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 11 of 11 reviews
September 26, 2017
I regularly have discussions with colleagues about what is the best way to develop code. We occasionally get stuck when we run into conflicts between the rules and principles we try to follow (modularity, clean code, don't repeat yourself, etc.). For example: 'If I do this, I'll be adding another moving part, but otherwise it's not modular. What should I do?'
This made me think about where all these principles and guidelines come from. We try to follow them so diligently, but how is it that we develop an intuition for 'code smells', and why do we feel compelled to get rid of them? I've never really consciously thought about this. I would instead latch onto the latest methodology or framework in the hopes to solve all my problems, yet always falling short. This can happen to such a degree that I become so attached to my language, framework or methodology that I fail to be able to see beyond it.
I've been paying more attention to how I feel when I write code, especially as codebases become larger and 'hairier'. I notice that I become increasingly anxious and overwhelmed trying to contain all possible behaviours of a program in my head - to think about 'if I add this thing, what could break?' or 'how is this loop behaving at each step'.
When I usually write a piece of code, I would mentally simulate what the code does, and if it worked correctly, I would leave this code in the program. Subsequently, I will always need to remember and repeat this mental work whenever I come in contact with this code. Because I have to keep this locked up in my head, I tend to not be able to think about my code in any other way.
I've always thought my difficulties were due to my own lack of coding ability, or short-attention span. But I now realise these things are just very mentally taxing and emotionally draining to me, and take energy and creativity away from what are often the real issues and goals of a project.
Whenever I talk with my colleagues now, I remember this article. I hope to be more humble with my own mental and emotional capacities, and take a step back from the latest methodologies and frameworks, and instead view them in terms of abstractions for using my own limited resources and capacities in a smarter way.
This made me think about where all these principles and guidelines come from. We try to follow them so diligently, but how is it that we develop an intuition for 'code smells', and why do we feel compelled to get rid of them? I've never really consciously thought about this. I would instead latch onto the latest methodology or framework in the hopes to solve all my problems, yet always falling short. This can happen to such a degree that I become so attached to my language, framework or methodology that I fail to be able to see beyond it.
"I have the feeling that one of the most important aspects of any computing tool is its influence on the thinking habits of those that try to use it, and because I have reasons to believe that that influence is many times stronger than is commonly assumed."
I've been paying more attention to how I feel when I write code, especially as codebases become larger and 'hairier'. I notice that I become increasingly anxious and overwhelmed trying to contain all possible behaviours of a program in my head - to think about 'if I add this thing, what could break?' or 'how is this loop behaving at each step'.
"I now suggest that we confine ourselves to the design and implementation of intellectually manageable programs. If someone fears that this restriction is so severe that we cannot live with it, I can reassure him: the class of intellectually manageable programs is still sufficiently rich to contain many very realistic programs for any problem capable of algorithmic solution. We must not forget that it is not our business to make programs, it is our business to design classes of computations that will display a desired behaviour."
When I usually write a piece of code, I would mentally simulate what the code does, and if it worked correctly, I would leave this code in the program. Subsequently, I will always need to remember and repeat this mental work whenever I come in contact with this code. Because I have to keep this locked up in my head, I tend to not be able to think about my code in any other way.
"I observe a cultural tradition [..] to regard the human mind as the supreme and autonomous master of its artefacts. But if I start to analyse the thinking habits of myself and of my fellow human beings, I come, whether I like it or not, to a completely different conclusion, viz. that the tools we are trying to use and the language or notation we are using to express or record our thoughts, are the major factors determining what we can think or express at all! The analysis of the influence that programming languages have on the thinking habits of its users, and the recognition that, by now, brainpower is by far our scarcest resource , they together give us a new collection of yardsticks for comparing the relative merits of various programming languages. The competent programmer is fully aware of the strictly limited size of his own skull ; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague."
I've always thought my difficulties were due to my own lack of coding ability, or short-attention span. But I now realise these things are just very mentally taxing and emotionally draining to me, and take energy and creativity away from what are often the real issues and goals of a project.
Whenever I talk with my colleagues now, I remember this article. I hope to be more humble with my own mental and emotional capacities, and take a step back from the latest methodologies and frameworks, and instead view them in terms of abstractions for using my own limited resources and capacities in a smarter way.
March 16, 2017
Great read. Still pretty relevant after 45 years.
"We must not forget that it is not our business to make programs, it is our business to design classes of computations that will display a desired behaviour.
"We must not forget that it is not our business to make programs, it is our business to design classes of computations that will display a desired behaviour.
March 11, 2020
Nearly 50 years later this is still relevant and it is also discussing history from 70 years ago that is relevant. Hardware advances still drive computing in ways that put more mental burden on programmers.
I love that there are historical elements that still seem to be the same today:
"Two opinions about programming date from those days. I mention them now, I shall return to them later. The one opinion was that a really competent programmer should be puzzle-minded and very fond of clever tricks; the other opinion was that programming was nothing more than optimizing the efficiency of the computational process, in one direction or another."
The other thing that I find interesting with multi-core, power thresholds being important and direct GPU APIs like DirectX12, Metal and Vulkan make statements like this resonate:
"as the power of available machines grew by a factor of more than a thousand, society's ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between ends and means."
To me though I think that a humble programmer today must acknowledge that simple well defined APIs shouldn't hide the complexity of hardware. We're better off from a hardware point of view by removing abstractions and accessing the hardware. On top of that though we should be pushing for better tools and education resources.
I love that there are historical elements that still seem to be the same today:
"Two opinions about programming date from those days. I mention them now, I shall return to them later. The one opinion was that a really competent programmer should be puzzle-minded and very fond of clever tricks; the other opinion was that programming was nothing more than optimizing the efficiency of the computational process, in one direction or another."
The other thing that I find interesting with multi-core, power thresholds being important and direct GPU APIs like DirectX12, Metal and Vulkan make statements like this resonate:
"as the power of available machines grew by a factor of more than a thousand, society's ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between ends and means."
To me though I think that a humble programmer today must acknowledge that simple well defined APIs shouldn't hide the complexity of hardware. We're better off from a hardware point of view by removing abstractions and accessing the hardware. On top of that though we should be pushing for better tools and education resources.
July 28, 2019
Can't recommend enough.
It starts with some background where hardware is seen as more fashionable compared to the software and continues why software will be a bigger problem and must improve. Then, it describes the necessary conditions for any breakthrough: understood benefits, economical costs, and feasibility.
First two are briefly explained and the last condition is extended and supported by manageable programs, reduced set of features, proofs and verification, large pattern libraries, better tools (i.e. programming languages), and abstractions (factored programming). He also shortly touches the road blockers; political status, unbalanced education, etc. Finally, he concludes accepting our limits and flaws isn't a bug but a feature to design and to develop for the future.
You will also find the source of many quotes that are seen frequently here and there and can have your own aha moments.
It starts with some background where hardware is seen as more fashionable compared to the software and continues why software will be a bigger problem and must improve. Then, it describes the necessary conditions for any breakthrough: understood benefits, economical costs, and feasibility.
First two are briefly explained and the last condition is extended and supported by manageable programs, reduced set of features, proofs and verification, large pattern libraries, better tools (i.e. programming languages), and abstractions (factored programming). He also shortly touches the road blockers; political status, unbalanced education, etc. Finally, he concludes accepting our limits and flaws isn't a bug but a feature to design and to develop for the future.
You will also find the source of many quotes that are seen frequently here and there and can have your own aha moments.
April 11, 2023
"There may also be political impediments. Even if we know how to educate tomorrow’s professional programmer, it is not certain that the society we are living in will allow us to do so. The first effect of teaching a methodology —rather than disseminating knowledge— is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable."
"This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!"
"This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!"
May 3, 2025
gave me a beautiful insight into the origin of programming and the days when it was a far reach. the difficulties of having a better computer and how to approach the task at hand.
hierarchical approach + humbleness towards computers and knowing our human limitations 🙌👏👏
hierarchical approach + humbleness towards computers and knowing our human limitations 🙌👏👏
November 15, 2017
great perspective from a great mind
July 23, 2023
Not much for gatekeeping and erudite ramblings but this is astonishingly relevant even today.
February 5, 2017
"We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers. - E.W Dijsktra
I planned to restart my readings of the EWDs with this humbling article (which was also his Turing Award Lecture). It deals with how insignificant a programmer is compared to the machines and the underlying concepts that s/he is pitted against. It elucidates the importance of good design and abstraction in Computer Science, the necessity to share your views when you feel something about a field is wrong but the herd-mentality tells you otherwise, the firm grounding in correctness for the programs that are written.
I did not understand a few things such as what "factored" solutions mean. I'll figure it out as I become a better Computer Scientist.
Like most EWDs this article has aged exceptionally well (even after four decades, we need more competent programmers who have good taste and can do justice to the powerful hardware that is available to them).
I would even go on to call it a classic timeless Computer Science must-read.
Trivia - A few famous quotes from Dijkstra come from this article. Read it and enjoy the 'aha' moments.
I planned to restart my readings of the EWDs with this humbling article (which was also his Turing Award Lecture). It deals with how insignificant a programmer is compared to the machines and the underlying concepts that s/he is pitted against. It elucidates the importance of good design and abstraction in Computer Science, the necessity to share your views when you feel something about a field is wrong but the herd-mentality tells you otherwise, the firm grounding in correctness for the programs that are written.
I did not understand a few things such as what "factored" solutions mean. I'll figure it out as I become a better Computer Scientist.
Like most EWDs this article has aged exceptionally well (even after four decades, we need more competent programmers who have good taste and can do justice to the powerful hardware that is available to them).
I would even go on to call it a classic timeless Computer Science must-read.
Trivia - A few famous quotes from Dijkstra come from this article. Read it and enjoy the 'aha' moments.
December 22, 2015
The lecture summarizes the programming practice from its inception to its future. The journey, about which Mr Dijsktra writes so eloquently, is a fascinating view of how and why some issues, such as lack of changes in hardware industry, made their way in the programmers' realm. It was a surprise to read the author advocating the retirement and removal of certain programming languages from existence, as most scientists would argue their usage for educational purposes.
The lecture is immensely humbling, and incredibly saturated with wisdom of programming. I would highly recommend reading this to anyone who wants to become a better programmer.
The lecture is immensely humbling, and incredibly saturated with wisdom of programming. I would highly recommend reading this to anyone who wants to become a better programmer.
Displaying 1 - 11 of 11 reviews