What do you think?
Rate this book
The Psychology of Computer Programming
This landmark 1971 classic is reprinted with a new preface, chapter-by-chapter commentary, and straight-from-the-heart observations on topics that affect the professional life of programmers.
Long regarded as one of the first books to pioneer a people-oriented approach to computing, The Psychology of Computer Programming endures as a penetrating analysis of the intelligence, skill, teamwork, and problem-solving power of the computer programmer.
Finding the chapters strikingly relevant to today's issues in programming, Gerald M. Weinberg adds new insights and highlights the similarities and differences between now and then. Using a conversational style that invites the reader to join him, Weinberg reunites with some of his most insightful writings on the human side of software engineering.
Topics include egoless programming, intelligence, psychological measurement, personality factors, motivation, training, social problems on large projects, problem-solving ability, programming language design, team formation, the programming environment, and much more.
Dorset House Publishing is proud to make this important text available to new generations of Weinberg fans and to encourage readers of the first edition to return to its valuable lessons.
Long regarded as one of the first books to pioneer a people-oriented approach to computing, The Psychology of Computer Programming endures as a penetrating analysis of the intelligence, skill, teamwork, and problem-solving power of the computer programmer.
Finding the chapters strikingly relevant to today's issues in programming, Gerald M. Weinberg adds new insights and highlights the similarities and differences between now and then. Using a conversational style that invites the reader to join him, Weinberg reunites with some of his most insightful writings on the human side of software engineering.
Topics include egoless programming, intelligence, psychological measurement, personality factors, motivation, training, social problems on large projects, problem-solving ability, programming language design, team formation, the programming environment, and much more.
Dorset House Publishing is proud to make this important text available to new generations of Weinberg fans and to encourage readers of the first edition to return to its valuable lessons.
292 pages, Paperback
First published January 1, 1971
About the author
Gerald M. Weinberg
91 books362 followersGerald Marvin Weinberg (October 27, 1933 – August 7, 2018) was an American computer scientist, author and teacher of the psychology and anthropology of computer software development.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 61 reviews
April 28, 2015
This isn't a book about "computer programming", but about computer programmers. It holds up remarkably well more than 40 years after its publication date because even though the technology changes rapidly, the people creating it do not.
Of course, not everything in the book has aged well. The discussion of "other programming tools" in the final chapter is fairly specific to an era of punch cards and shared terminals and should mostly be skipped. Also, there are some fairly dated views on the roles of women in the workplace and how they can't match up to men--not that Weinberg endorses these views, but it's clear that this is a book from a different era (that said, women in tech is still a problem now).
Overall, a very worthwhile read. We need more tech books that focus on the people and not the technology itself.
Some of the key ideas I found especially memorable:
* We should look at programming as a human activity, not just a mathematical, scientific, or technological one.
* Most programs are built by teams, so we need to look not only at how an individual interacts with a computer, but also how many individuals building software interact with each other.
* In most professions, you look at the work of others to learn. Not so in coding. We rarely read other people's code and prefer to learn by writing things ourselves and repeating everyone else's mistakes. This situation has improved slightly since Weinberg wrote the book thanks to the explosion of open source, but it's still very rare for a programmer to sit down and just read code as a learning exercise.
* Egoless programming: see the code you write not as part of yourself, but as independent objects owned by the team. That way, you don't see flaws in the code as flaws in your character, and you become much better at seeking out feedback and handling criticism.
* Good programming language design is primarily about taking into account the limitations of the human mind. We can't hold or process too much information in our heads, so languages need to be designed around the principles of uniformity, compactness, locality, and linearity.
* Programming is a nascent field and we need a lot more research to figure out how to do it effectively. Sadly, more than 40 years later, we've done relatively little rigorous research and still don't seem to be much closer to knowing the answers.
Some of my favorite quotes from the book:
The material which follows is food for thought, not a substitute for it.
Computer programming is a human activity. One could hardly dispute this assertion, and yet, perhaps because of the emphasis placed on the machine aspects of programming, many people--many programmers--have never considered programming in this light.
Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples--both good and bad--to facilitate learning. But how many programmers learn to write programs by reading programs? A few, but not many.
Specifications evolve together with programs and programmers. Writing a program is a process of learning--both for the programmer and the person who commissions the program.
The average programming manager would prefer that a project be estimated at twelve months and take twelve then that the same project be estimated at six months and take nine.
Fisher's Fundamental Theorem states--in terms appropriate to the present context--that the better adapted a system is to a particular environment, the less adaptable it is to new environments.
Psychology is the psychology of 18-year-old college freshmen.
Maxwell, the great physicist, once said, "To measure is to know," and his words are often taken as a motto by other sciences. What Maxwell probably meant was "To know how to measure is to know," or even better, "To know what to measure is to know."
The organization chart is a nice toy for a manager, but little programming work would ever get done if interactions among programmers has to follow its narrow, straight lines.
John von Neumann himself was perhaps the first programmer to recognize his inadequacies with respect to examination of his own work. Those who knew him have said that he was constantly asserting what a lousy programmer he was, and that he incessantly pushed his programs on other people to read for errors and clumsiness. Yet the common image of von Neumann today is of the unparalleled computing genius--flawless in his every action. And indeed, there can be no doubt of von Neumann's genius. His very ability to realize his human limitations put him head and shoulders above the average programmer today.
As a rough rule, three programmers organized into a team can do only twice the work of a single programmer same ability--because of time spent coordination problems. Moreover, three groups of three programmers to do only twice the work of a single group--or four times the work single programmer--for the same reason.
The basic rule for size and composition of programming teams seem to be this--for the best programming at the least cost, give the best possible programs you can find sufficient time so you need the smallest number of them. When you have to work faster, or with less experienced people, costs and uncertainties will rise. In any case, the worst way to do programming project is to hire a horde of trainees and put them to work under pressure and without supervision--although this is the most common practice today.
Programmers, being people who tend to value creative event and professional competence, tend to put their stock in people whom they perceive to be good at the things they do. Thus, it is easier to exert leadership over--to influence--programmers by being a soft-spoken programming wizard than by being the world's fastest-talking salesman.
If a manager wants to run a stable project, he would do well to follow this simple maxim: If a programmer is indispensable, get rid of him as quickly as possible.
It is a well-known psychological principle that in order to maximize the rate of learning, the subject must be fed back information on how well or poorly he is doing. What is perhaps not so well known is that people who feel that their performance is being judged but who have no adequate information on how well they are doing will test the system by trying certain variations.
The hierarchical organization, which so many of our projects seem to emulate, comes to us not from the observation of successful machines or natural systems, but from the nineteenth century successes of the Austrian Army.
Whenever a supervisor is responsible for work he does not understand, he begins to reward workers not for work, but for the appearance of work. Programmers who arrive early in the morning are thought to be better programmers than ones who are seen to arrive after official starting time. Programmers who work late, however, may not be rewarded because the manager is not likely to see that they are working late. Programmers who are seen taking to there are not considered to be working, because the manager has an image that programming work involves the solitary thinker scratching out secret messages to the computer.
The amateur, then, is learning about his problem, and any learning about programming he does may be a nice frill or may be a nasty impediment for him. The professional, conversely, is learned about his profession--programming--and the problem being programmed is only one incidental step in the process of his development.
A large proportion of the variance between programmers on any job can be attributed to a different conception of what is to be done.
Lacking any objective measure, we often judge how difficult a problem is by how hard a programmer works on it. Using this sort of measure, we can easily fall into believing that the worst programmers are the best--because they work so hard at it.
Once the solution has been shown, it is easy to forget the puzzlement that existed before it was solved. For one thing, one of the most common reasons for problem difficulty is overlooking of some factor. Once we have discovered or been told this factor is significant, working out the solution is trivial. If we present the problem to someone else, we will usually present him with that factor, which immediately solves nine-tenths of the problem for him. He cannot imagine why we had such trouble, and soon we begin to wonder ourselves.
The explanations for success given by some programmers bring to mind the story of the village idiot who won the monthly lottery. When asked to explain how he picked the winning number, he said, "Well, my lucky number is seven, and this was be seventh lottery this year, so I multiplied seven times seven and got the winning number--63. And, when someone tried to tell him that seven times seven was forty-nine, he merely answered with disdain, "Oh, you're just jealous"--which, of course, was true.
The two major influences we can exert on a programmer's performance are on the desire he feels for working and on what he knows that is needed for the job. The first is called motivation and the second is called training, or, if it is sufficiently general, education. But little is known about why programmers program harder, or whether they are already programming too hard for their own good. Possibly even less is known about educating programmers, even though vast sums have been spent on training schemes.
In a way, the reason it is so hard to attribute the source of programming inefficiency to either programmer or programming language is that if we had ideal programmers, programming languages would be be necessary. It is a psychological which prevents us from writing out problem specifications directly in machine language.
Let's face up to it: people don't think the same way that computers do--that's why we use computers. Programming is at best a communication between two alien species, and programming languages with all their systems paraphernalia are an attempt to make communication simpler for one of those species. Which one? Not the computer, certainly, for nobody ever heard a complaint from a computer that it couldn't do the work.
Of course, not everything in the book has aged well. The discussion of "other programming tools" in the final chapter is fairly specific to an era of punch cards and shared terminals and should mostly be skipped. Also, there are some fairly dated views on the roles of women in the workplace and how they can't match up to men--not that Weinberg endorses these views, but it's clear that this is a book from a different era (that said, women in tech is still a problem now).
Overall, a very worthwhile read. We need more tech books that focus on the people and not the technology itself.
Some of the key ideas I found especially memorable:
* We should look at programming as a human activity, not just a mathematical, scientific, or technological one.
* Most programs are built by teams, so we need to look not only at how an individual interacts with a computer, but also how many individuals building software interact with each other.
* In most professions, you look at the work of others to learn. Not so in coding. We rarely read other people's code and prefer to learn by writing things ourselves and repeating everyone else's mistakes. This situation has improved slightly since Weinberg wrote the book thanks to the explosion of open source, but it's still very rare for a programmer to sit down and just read code as a learning exercise.
* Egoless programming: see the code you write not as part of yourself, but as independent objects owned by the team. That way, you don't see flaws in the code as flaws in your character, and you become much better at seeking out feedback and handling criticism.
* Good programming language design is primarily about taking into account the limitations of the human mind. We can't hold or process too much information in our heads, so languages need to be designed around the principles of uniformity, compactness, locality, and linearity.
* Programming is a nascent field and we need a lot more research to figure out how to do it effectively. Sadly, more than 40 years later, we've done relatively little rigorous research and still don't seem to be much closer to knowing the answers.
Some of my favorite quotes from the book:
The material which follows is food for thought, not a substitute for it.
Computer programming is a human activity. One could hardly dispute this assertion, and yet, perhaps because of the emphasis placed on the machine aspects of programming, many people--many programmers--have never considered programming in this light.
Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples--both good and bad--to facilitate learning. But how many programmers learn to write programs by reading programs? A few, but not many.
Specifications evolve together with programs and programmers. Writing a program is a process of learning--both for the programmer and the person who commissions the program.
The average programming manager would prefer that a project be estimated at twelve months and take twelve then that the same project be estimated at six months and take nine.
Fisher's Fundamental Theorem states--in terms appropriate to the present context--that the better adapted a system is to a particular environment, the less adaptable it is to new environments.
Psychology is the psychology of 18-year-old college freshmen.
Maxwell, the great physicist, once said, "To measure is to know," and his words are often taken as a motto by other sciences. What Maxwell probably meant was "To know how to measure is to know," or even better, "To know what to measure is to know."
The organization chart is a nice toy for a manager, but little programming work would ever get done if interactions among programmers has to follow its narrow, straight lines.
John von Neumann himself was perhaps the first programmer to recognize his inadequacies with respect to examination of his own work. Those who knew him have said that he was constantly asserting what a lousy programmer he was, and that he incessantly pushed his programs on other people to read for errors and clumsiness. Yet the common image of von Neumann today is of the unparalleled computing genius--flawless in his every action. And indeed, there can be no doubt of von Neumann's genius. His very ability to realize his human limitations put him head and shoulders above the average programmer today.
As a rough rule, three programmers organized into a team can do only twice the work of a single programmer same ability--because of time spent coordination problems. Moreover, three groups of three programmers to do only twice the work of a single group--or four times the work single programmer--for the same reason.
The basic rule for size and composition of programming teams seem to be this--for the best programming at the least cost, give the best possible programs you can find sufficient time so you need the smallest number of them. When you have to work faster, or with less experienced people, costs and uncertainties will rise. In any case, the worst way to do programming project is to hire a horde of trainees and put them to work under pressure and without supervision--although this is the most common practice today.
Programmers, being people who tend to value creative event and professional competence, tend to put their stock in people whom they perceive to be good at the things they do. Thus, it is easier to exert leadership over--to influence--programmers by being a soft-spoken programming wizard than by being the world's fastest-talking salesman.
If a manager wants to run a stable project, he would do well to follow this simple maxim: If a programmer is indispensable, get rid of him as quickly as possible.
It is a well-known psychological principle that in order to maximize the rate of learning, the subject must be fed back information on how well or poorly he is doing. What is perhaps not so well known is that people who feel that their performance is being judged but who have no adequate information on how well they are doing will test the system by trying certain variations.
The hierarchical organization, which so many of our projects seem to emulate, comes to us not from the observation of successful machines or natural systems, but from the nineteenth century successes of the Austrian Army.
Whenever a supervisor is responsible for work he does not understand, he begins to reward workers not for work, but for the appearance of work. Programmers who arrive early in the morning are thought to be better programmers than ones who are seen to arrive after official starting time. Programmers who work late, however, may not be rewarded because the manager is not likely to see that they are working late. Programmers who are seen taking to there are not considered to be working, because the manager has an image that programming work involves the solitary thinker scratching out secret messages to the computer.
The amateur, then, is learning about his problem, and any learning about programming he does may be a nice frill or may be a nasty impediment for him. The professional, conversely, is learned about his profession--programming--and the problem being programmed is only one incidental step in the process of his development.
A large proportion of the variance between programmers on any job can be attributed to a different conception of what is to be done.
Lacking any objective measure, we often judge how difficult a problem is by how hard a programmer works on it. Using this sort of measure, we can easily fall into believing that the worst programmers are the best--because they work so hard at it.
Once the solution has been shown, it is easy to forget the puzzlement that existed before it was solved. For one thing, one of the most common reasons for problem difficulty is overlooking of some factor. Once we have discovered or been told this factor is significant, working out the solution is trivial. If we present the problem to someone else, we will usually present him with that factor, which immediately solves nine-tenths of the problem for him. He cannot imagine why we had such trouble, and soon we begin to wonder ourselves.
The explanations for success given by some programmers bring to mind the story of the village idiot who won the monthly lottery. When asked to explain how he picked the winning number, he said, "Well, my lucky number is seven, and this was be seventh lottery this year, so I multiplied seven times seven and got the winning number--63. And, when someone tried to tell him that seven times seven was forty-nine, he merely answered with disdain, "Oh, you're just jealous"--which, of course, was true.
The two major influences we can exert on a programmer's performance are on the desire he feels for working and on what he knows that is needed for the job. The first is called motivation and the second is called training, or, if it is sufficiently general, education. But little is known about why programmers program harder, or whether they are already programming too hard for their own good. Possibly even less is known about educating programmers, even though vast sums have been spent on training schemes.
In a way, the reason it is so hard to attribute the source of programming inefficiency to either programmer or programming language is that if we had ideal programmers, programming languages would be be necessary. It is a psychological which prevents us from writing out problem specifications directly in machine language.
Let's face up to it: people don't think the same way that computers do--that's why we use computers. Programming is at best a communication between two alien species, and programming languages with all their systems paraphernalia are an attempt to make communication simpler for one of those species. Which one? Not the computer, certainly, for nobody ever heard a complaint from a computer that it couldn't do the work.
April 3, 2014
TL;DR: don't waste your time, browse this blog instead.
I was lured to this book by the title and ratings, and the latter still puzzle me.
First of all, I cannot praise this book based on its contents because if there were any insights at the time of the first edition, they are at best commonplace today. How people engage in programming has changed a lot—environment, tools, languages, standard practices, they all have changed. Psychology has changed a lot (and the guy still swears by MBTI, that tells you something). But most importantly, Weinberg doesn't bother with gathering data to support his ideas. OK, maybe he didn't have the time to do research then (huh?), but this is the 25th anniversary edition of the book. He took trouble to add "hindsight" comments to each chapter, and none of them point to any old or modern research, either by the author himself, or by anybody else. I wonder if he ever did any studies at all, except for the amateurish stuff.
So, nothing novel, plus the style is really bad. Tedious writing, lengthy rants about (now) dated practices and technologies, weird personal anecdotes (so weird, they seem completely made up), plain jokes. To give you a taste of how ridiculous his writing is, here's an excerpt from the epilogue:
“Can there be any doubt that if Hitler had computers at his command, one of the first application would have been keeping closer track on Jews and Gypsies so that all who should have gone to the ovens did go to the ovens? Can there by any doubt that if Pilate had computers, they would have been used to store the information gathered from informers, the better to crucify those that were crying out for crucifixion by their heretical zeal? Can there be any doubt that somewhere in our country today some human beings are using computers as just another, finer weapon in their arsenal of ways to subjugate other human beings to their wishes—to their conception of the proper life of man?”
WAT?
Definitely not a timeless classic.
On a more constructive note: Take a look at It Will Never Work in Theory instead.
I was lured to this book by the title and ratings, and the latter still puzzle me.
First of all, I cannot praise this book based on its contents because if there were any insights at the time of the first edition, they are at best commonplace today. How people engage in programming has changed a lot—environment, tools, languages, standard practices, they all have changed. Psychology has changed a lot (and the guy still swears by MBTI, that tells you something). But most importantly, Weinberg doesn't bother with gathering data to support his ideas. OK, maybe he didn't have the time to do research then (huh?), but this is the 25th anniversary edition of the book. He took trouble to add "hindsight" comments to each chapter, and none of them point to any old or modern research, either by the author himself, or by anybody else. I wonder if he ever did any studies at all, except for the amateurish stuff.
So, nothing novel, plus the style is really bad. Tedious writing, lengthy rants about (now) dated practices and technologies, weird personal anecdotes (so weird, they seem completely made up), plain jokes. To give you a taste of how ridiculous his writing is, here's an excerpt from the epilogue:
“Can there be any doubt that if Hitler had computers at his command, one of the first application would have been keeping closer track on Jews and Gypsies so that all who should have gone to the ovens did go to the ovens? Can there by any doubt that if Pilate had computers, they would have been used to store the information gathered from informers, the better to crucify those that were crying out for crucifixion by their heretical zeal? Can there be any doubt that somewhere in our country today some human beings are using computers as just another, finer weapon in their arsenal of ways to subjugate other human beings to their wishes—to their conception of the proper life of man?”
WAT?
Definitely not a timeless classic.
On a more constructive note: Take a look at It Will Never Work in Theory instead.
January 23, 2022
It's a rare technical book that is worth a damn after five years, let alone more than 50. While technology has changed immensely, the basics of computer programming remain the same. Weinberg offers a social study of programming, followed by questions for programmers and programming managers.
4 of 5 developers enjoy code review
These questions are the best part of the book. "When was the last time you read a program written by someone else? When was the last time someone read one of your programs? Was it your manager?" Like, what did I do to get called out like this?. There are good sections on motivation, and how money is rarely enough for good programmers, which is true (though looking at levels.fyi I could use a raise, and software is the only career in this capitalist hellscape that is actually well compensated), and how egoless programming helps build robust software. Simply posing these questions to your software engineering team could reveal some very interesting truths and issues.
There's also a lot of thoroughly deprecated engineering culture here. The example language is PL/I, the example machine an IBM 360 series mainframe. While we no longer line up to submit our batches of punchcards to the almighty computer, we still have organizational barriers between developers and infrastructure. While process protects us from technical debt, security holes, and general anarchy, process is a greater barrier to getting things done at my job than any technical issue.
The reason why I've docked this review a star is that while I think Weinberg is right, he's right in theory and often lacks the evidence to support his claims, evidence which according to Valia's review of this book is now available. The one experiment, which is fascinating, compares groups of programmers on the same task. One group was told to write an efficient program, the other group to just get it done. The efficient group took 5x the time, but their programs used 10% of the computing resources on average.
The Psychology of Computer Programming has many fascinating and provocative questions, but gets lost in a tangle of arguments without evidence. And there's also a faith that despite 50 years of exponential change in processor speed, memory, and quality of tooling, the fundamentals of programming are the same.
4 of 5 developers enjoy code review
These questions are the best part of the book. "When was the last time you read a program written by someone else? When was the last time someone read one of your programs? Was it your manager?" Like, what did I do to get called out like this?. There are good sections on motivation, and how money is rarely enough for good programmers, which is true (though looking at levels.fyi I could use a raise, and software is the only career in this capitalist hellscape that is actually well compensated), and how egoless programming helps build robust software. Simply posing these questions to your software engineering team could reveal some very interesting truths and issues.
There's also a lot of thoroughly deprecated engineering culture here. The example language is PL/I, the example machine an IBM 360 series mainframe. While we no longer line up to submit our batches of punchcards to the almighty computer, we still have organizational barriers between developers and infrastructure. While process protects us from technical debt, security holes, and general anarchy, process is a greater barrier to getting things done at my job than any technical issue.
The reason why I've docked this review a star is that while I think Weinberg is right, he's right in theory and often lacks the evidence to support his claims, evidence which according to Valia's review of this book is now available. The one experiment, which is fascinating, compares groups of programmers on the same task. One group was told to write an efficient program, the other group to just get it done. The efficient group took 5x the time, but their programs used 10% of the computing resources on average.
The Psychology of Computer Programming has many fascinating and provocative questions, but gets lost in a tangle of arguments without evidence. And there's also a faith that despite 50 years of exponential change in processor speed, memory, and quality of tooling, the fundamentals of programming are the same.
February 10, 2019
This book is misnamed, as the author admits. It should be named "The Anthropology of Computer Programming." It studies the culture of computer programming rather than the psychology of the practice. Fortunately, despite being written over forty years ago, it succeeds at its task for the reader today as well as for the original reader.
If you can move past the references to dated languages and programming practices, this book elucidates many observations about how programmers work. It's like reading an anthropology of a long-hidden culture from decades ago. From one who works in computer programming, the cultural fruit of these observations can be seen in labs today.
To be frank, I've never felt that I've truly understood my peers in the lab. I've done well with the computer - with expressing myself through programs. So many of my peers are socially passive in their demeanor. I'm outgoing, even energetic. The cultural analysis in this book, though dated, helps me see this culture more clearly. It helps me feel more at home in my own environment - and perhaps also, in my own skin. As such, this book achieved its goal in my life, and for that, I am sincerely grateful.
If you can move past the references to dated languages and programming practices, this book elucidates many observations about how programmers work. It's like reading an anthropology of a long-hidden culture from decades ago. From one who works in computer programming, the cultural fruit of these observations can be seen in labs today.
To be frank, I've never felt that I've truly understood my peers in the lab. I've done well with the computer - with expressing myself through programs. So many of my peers are socially passive in their demeanor. I'm outgoing, even energetic. The cultural analysis in this book, though dated, helps me see this culture more clearly. It helps me feel more at home in my own environment - and perhaps also, in my own skin. As such, this book achieved its goal in my life, and for that, I am sincerely grateful.
November 18, 2009
I picked up this book on a whim, purely based on the title. I didn't look at the copyright info or the introduction first, where I would have learned that Gerald Weinberg first wrote about programmer psychology in 1971.
To my surprise, much of it aged well. Weinberg took an interesting approach when releasing a 25th anniversary "silver edition." Instead of editing out all of his references to COBOL, Fortran, and PL/I, or replacing them with anecdotes about C++ and Java, he left everything intact. Instead, he includes a conversational little "Comments about Chapter X" section after every section.
An interesting result is that if you read less linearly than I do, you can actually skip ahead to those comments and see whether or not the author himself thinks that the chapter is still worth reading! Brilliant.
To my surprise, much of it aged well. Weinberg took an interesting approach when releasing a 25th anniversary "silver edition." Instead of editing out all of his references to COBOL, Fortran, and PL/I, or replacing them with anecdotes about C++ and Java, he left everything intact. Instead, he includes a conversational little "Comments about Chapter X" section after every section.
An interesting result is that if you read less linearly than I do, you can actually skip ahead to those comments and see whether or not the author himself thinks that the chapter is still worth reading! Brilliant.
November 2, 2014
An insightful collection of essays that still resonate today even though some of its anecdotes reference punch cards. Egoless programming remains its strongest practice and one that is still not the norm. It's also staggering in its prescience. Although sometimes under different names, he predicts unit testing, code analysis tools, and countless other great ideas. I highly recommended it.
September 26, 2021
Everyone who works as a developer should read this book, which was written 40+ years ago and is as prescient as any Medium blog post today only more timeless.
December 27, 2019
Some very good take-aways to keep in mind WHILST your writing your code.
December 2, 2012
Weinberg was one of the earliest authors who realized that computer programming is a human activity, and has a lot in common with other human activities. A programmer is reluctant to see the flaws in his code, so it must be checked by others. A programming language should be orthogonal because it is hard for a programmer to keep in his head, which features are enabled in which context. A programming project could never move forward if all interactions between the programmers follow the up-and-down lines of an org chart, and not informal horizontal lines. Managers are advised: "If a programmer is indispensable, get rid of him as quickly as possible," because "people are sometimes inconsiderate enough of their managers to get sick, to get drafted, or to die," and this should not spell ruin for the project. Adding more inexperienced programmers to a project most likely will not speed it up. Copy-pasted code is error-prone because mistakes introduced during the copy-pasting are hard to spot; better to use parametrized code in one place. These seem like truisms now, but remember that this was written over 40 years ago! There are lots of amusing anecdotes illustrating the author's theses.
March 28, 2019
Recent I have read The Psychology of Computer Programming, written by Gerald M. Weinberg. The book was originally published in 1971, though it got republished in 2011. (I read it on a kindle paperwhite and it looked great! So don’t worry about the age of the book in case you fear it won’t look good in e-book format).
Even though the book was written in a time before the public internet, Java, Javascript, smartphones and many more things we take for granted today, a lot of the content still rings true today.
I would actually recommend that software engineers still read this book even today. It has helped give me more appreciation for the soft skills necessary in the profession.
I've highlighted and discussed some points made in the book on my blog, which can give you an idea of the type of content the book discusses: https://dylanmeeus.github.io/posts/ps...
Even though the book was written in a time before the public internet, Java, Javascript, smartphones and many more things we take for granted today, a lot of the content still rings true today.
I would actually recommend that software engineers still read this book even today. It has helped give me more appreciation for the soft skills necessary in the profession.
I've highlighted and discussed some points made in the book on my blog, which can give you an idea of the type of content the book discusses: https://dylanmeeus.github.io/posts/ps...
August 8, 2015
The book has great early chapters. However, I do find the latter part of the book a bit more tedious as the author is trying to address a more social aspect of computer programming from a technical standpoint. I think it's hard to write about something social when the writer is approaching it as an engineering problem to solve.
There are few major takeaways on computer programming:
1. Think of computer programming as a social event. It is a group of people trying to build a product together. It is important to think about how these people are going to collaborate, how they communicate about their common goals, and how they measure the progress of building a product.
2. Programming is like writing. To practice programming = program more + to reading more computer programs
3. The goal is to build a program that meets the requirement (features, easy to change in the future, easy to detect problems, etc.). Writing a perfect program should never be the goal because we don't know what a perfect, or even good program looks like.
Great quotes:
Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples—both good and bad—to facilitate learning. But how many programmers learn to write programs by reading programs? A few, but not many. And with the advent of terminals, things are getting worse, for the programmer may not even see his own program in a form suitable for reading.
Perhaps if we want to understand how programmers program —to lift the veil of the programming mystique—we could fruitfully begin by seeing what is to be learned from the reading of programs.
When the programmer includes something that is intended to overcome some limitation of the machine, he rarely marks it explicitly as such. Although this omission adds to the intrigue of reading programs, it does penalize the program when, for example, it is transferred to another machine. The programmer may not even be aware that some of his coding is intended to compensate for a limitation of the machine, in which case he could hardly be expected to mark it.
Not all historic code can be so easily differentiated as these examples might imply. In particular, the larger a program grows, the more diffuse are the effects of particular historical choices made early in its life. Even the very structure of the program may be determined by the size and composition of the programming group that originally wrote it—since the work had to be divided up among a certain number of people, each of whom had certain strengths and weaknesses.
There will always remain the fact that, in most cases, we do not know what we want to do until we have taken a flying leap at programming it. Specifications evolve together with programs and programmers. Writing a program is a process of learning—both for the programmer and the person who commissions the program.
The most important reason for studying the process by which programs are written by people is not to make the programs more efficient, more compact, cheaper, or more easily understood. Instead, the most important gain is the prospect of getting from our programs what we really want—rather than just whatever we can manage to produce in our fumbling, bumbling way.
Looking honestly at the situation, we are never looking for the best program, seldom looking for a good one, but always looking for one that meets the requirements.
If a program doesn't work, measures of efficiency, of adaptability, or of cost of production have no meaning.
One of the recurring problems in programming is meeting schedules, and a program that is late is often worthless.
Few programmers of any experience would contradict the assertion that most programs are modified in their lifetime. Why, then, when we are forced to modify programs do we find it such a Herculean task that we often decide to throw them away and start over? Reading programs gives us some insight, for we rarely find a program that contains any evidence of having been written with an eye to subsequent modification.
The question of what makes a good program is not a simple one, and may not even be a proper question. Each program has to be considered on its own merits and in relation to its own surroundings. Some of the important factors are:
1. Does the program meet specifications? Or, rather, how well does it meet specifications?
2. Is it produced on schedule, and what is the variability in the schedule that we can expect from particular approaches?
3. Will it be possible to change the program when conditions change? How much will it cost to make the change?
4. How efficient is the program, and what do we mean by efficiency? Are we trading efficiency in one area for inefficiency in another? In the future, and particularly in the discussion of this book, we should refrain from using the concept "good program" or "good programmer" as if it were something universally agreed upon, or something that even can be universally agreed upon, or something that even should be universally agreed upon.
There are few major takeaways on computer programming:
1. Think of computer programming as a social event. It is a group of people trying to build a product together. It is important to think about how these people are going to collaborate, how they communicate about their common goals, and how they measure the progress of building a product.
2. Programming is like writing. To practice programming = program more + to reading more computer programs
3. The goal is to build a program that meets the requirement (features, easy to change in the future, easy to detect problems, etc.). Writing a perfect program should never be the goal because we don't know what a perfect, or even good program looks like.
Great quotes:
Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples—both good and bad—to facilitate learning. But how many programmers learn to write programs by reading programs? A few, but not many. And with the advent of terminals, things are getting worse, for the programmer may not even see his own program in a form suitable for reading.
Perhaps if we want to understand how programmers program —to lift the veil of the programming mystique—we could fruitfully begin by seeing what is to be learned from the reading of programs.
When the programmer includes something that is intended to overcome some limitation of the machine, he rarely marks it explicitly as such. Although this omission adds to the intrigue of reading programs, it does penalize the program when, for example, it is transferred to another machine. The programmer may not even be aware that some of his coding is intended to compensate for a limitation of the machine, in which case he could hardly be expected to mark it.
Not all historic code can be so easily differentiated as these examples might imply. In particular, the larger a program grows, the more diffuse are the effects of particular historical choices made early in its life. Even the very structure of the program may be determined by the size and composition of the programming group that originally wrote it—since the work had to be divided up among a certain number of people, each of whom had certain strengths and weaknesses.
There will always remain the fact that, in most cases, we do not know what we want to do until we have taken a flying leap at programming it. Specifications evolve together with programs and programmers. Writing a program is a process of learning—both for the programmer and the person who commissions the program.
The most important reason for studying the process by which programs are written by people is not to make the programs more efficient, more compact, cheaper, or more easily understood. Instead, the most important gain is the prospect of getting from our programs what we really want—rather than just whatever we can manage to produce in our fumbling, bumbling way.
Looking honestly at the situation, we are never looking for the best program, seldom looking for a good one, but always looking for one that meets the requirements.
If a program doesn't work, measures of efficiency, of adaptability, or of cost of production have no meaning.
One of the recurring problems in programming is meeting schedules, and a program that is late is often worthless.
Few programmers of any experience would contradict the assertion that most programs are modified in their lifetime. Why, then, when we are forced to modify programs do we find it such a Herculean task that we often decide to throw them away and start over? Reading programs gives us some insight, for we rarely find a program that contains any evidence of having been written with an eye to subsequent modification.
The question of what makes a good program is not a simple one, and may not even be a proper question. Each program has to be considered on its own merits and in relation to its own surroundings. Some of the important factors are:
1. Does the program meet specifications? Or, rather, how well does it meet specifications?
2. Is it produced on schedule, and what is the variability in the schedule that we can expect from particular approaches?
3. Will it be possible to change the program when conditions change? How much will it cost to make the change?
4. How efficient is the program, and what do we mean by efficiency? Are we trading efficiency in one area for inefficiency in another? In the future, and particularly in the discussion of this book, we should refrain from using the concept "good program" or "good programmer" as if it were something universally agreed upon, or something that even can be universally agreed upon, or something that even should be universally agreed upon.
November 1, 2015
Although it was first published in 1971, most of this book still feels up-to-date, as long as you can ignore the occasional reference to punch cards and tapes. Despite all the change in software development, apparently some things don't change much. How we interact with each other, computers, and source code, remain stable.
The text still seems relevant, and it contains some anecdotes that I recognise because they simply seem to have entered the general software development mythology. Apparently, this book is the source of some of these.
Still, I didn't like it much, because it's such a dry read. I simply found it neither entertaining nor sufficiently educational, although it did have a few gems here and there.
The text still seems relevant, and it contains some anecdotes that I recognise because they simply seem to have entered the general software development mythology. Apparently, this book is the source of some of these.
Still, I didn't like it much, because it's such a dry read. I simply found it neither entertaining nor sufficiently educational, although it did have a few gems here and there.
December 19, 2016
❗ The book is must for everyone who participate in software development process.
45 years old book, but it aged well. Human are still the same. It would be nice to see how Agile methodology was grounded on psychology, what it solves and what not.
More important -there is no modern books on the same topic.
The book is very dense. It touched lots of topics. For example, there is an opinion that programming was more female-friendly in 60-70s. Author shows stereotypes about females - he suggests tile of Team-Mother, which is different from team lead. He also likes out that females are less likely to be promoted
I needed time to think after several pages. Questions after each chapter helped to see possible differences between places I worked and why some places were better.
45 years old book, but it aged well. Human are still the same. It would be nice to see how Agile methodology was grounded on psychology, what it solves and what not.
More important -there is no modern books on the same topic.
The book is very dense. It touched lots of topics. For example, there is an opinion that programming was more female-friendly in 60-70s. Author shows stereotypes about females - he suggests tile of Team-Mother, which is different from team lead. He also likes out that females are less likely to be promoted
I needed time to think after several pages. Questions after each chapter helped to see possible differences between places I worked and why some places were better.
August 11, 2011
Like Mythical Man Month, this book was written in another era of computing. Nonetheless, many concepts, like egoless programming, and the effect of seemingly unrelated workplace changes to coding, like the location of the coffee machine, still apply today. Even the more aged comments are still informative of the history of computing for programmers like myself, who've grown in the world of fast personal computers and very advanced operating systems. I think I understand my co-workers better now that I've read this book.
I heartily recommend this book to those working with code or coders.
I heartily recommend this book to those working with code or coders.
April 5, 2019
.
.
Preface
Suggestions for Course Use
Contents
Part 1: Programming as Human Performance
1. Reading Programs
2. What Makes a Good Program?
3. How Can We Study Programming?
Part 2: Programming as a Social Activity
4. The Programming Group
5. The Programming Team
6. The Programming Project
Part 3: Programming as an Individual Activity
7. Variations In The Programming Task
8. Personality Factors
9. Intelligence, or Problem-Solving Ability
10. Motivation, Training, and Experience
Part 4: Programming Tools
11. Programming Languages
12. Some Principles For Programming Language Design
13. Other Programming Tools
Part 5: Epilogue
Index
.
Preface
Suggestions for Course Use
Contents
Part 1: Programming as Human Performance
1. Reading Programs
2. What Makes a Good Program?
3. How Can We Study Programming?
Part 2: Programming as a Social Activity
4. The Programming Group
5. The Programming Team
6. The Programming Project
Part 3: Programming as an Individual Activity
7. Variations In The Programming Task
8. Personality Factors
9. Intelligence, or Problem-Solving Ability
10. Motivation, Training, and Experience
Part 4: Programming Tools
11. Programming Languages
12. Some Principles For Programming Language Design
13. Other Programming Tools
Part 5: Epilogue
Index
June 2, 2012
I read this back in college (20-some years ago), several times; it's an entertaining investigation of the people who create software - and how their psychology affects the resulting products. Even after 20 years I recall Weinberg talking about a case where petty jealousies in a programming team led to errors in program output years later (after an upgrade) - errors that were only uncovered after some reminiscing by the original team gave a clue to where the new error might be: not in the section that was exhibiting the error, but in a completely different section of code.
May 20, 2011
+ a book with code snippets in PL/I and memory measured in KB is fun to read
+ anecdotes supporting the author's ideas are also fun
+ maybe there were some good points I'll find useful - we'll see
- the language is a bit complicated: some sentences are just huge and hard to parse
- there's too much introductions, motivations and random musings
- some of the questions posed are obsolete, some have been answered definitively during the last 40 years
+ anecdotes supporting the author's ideas are also fun
+ maybe there were some good points I'll find useful - we'll see
- the language is a bit complicated: some sentences are just huge and hard to parse
- there's too much introductions, motivations and random musings
- some of the questions posed are obsolete, some have been answered definitively during the last 40 years
September 13, 2013
I was very disappointed. The title seemed so promising, but the book was just full of anecdotes and half-baked ideas. To his credit, Weinberg says early on that he only wrote the book to get people thinking about the psychology of computer programming. And he really did get me thinking about it and gave some interesting insights, but I was really hoping he would have thought things out more than he had.
October 21, 2013
This is an excellent book, the ideas it promotes are still relevant today (several decades after the it was published).
It is quite interesting to observe how languages evolved, how some of them got things right... And how some are throwing programmers into traps that were known many years ago.
Overall, I really enjoyed this one!
It is quite interesting to observe how languages evolved, how some of them got things right... And how some are throwing programmers into traps that were known many years ago.
Overall, I really enjoyed this one!
July 14, 2013
amazing book! it's interesting to read about programmers and their problems 40 years ago and see that actually nothing's changed. great great great book. I have enjoyed reading it and surely learnt a lot during reading.
June 3, 2014
A fantastic, practical introduction to thinking about the psychology of computer programming.
Unlike most books, the author isn't afraid to say "we don't know" when there's a question they don't have the answer to. It's a refreshingly honest feeling book.
Unlike most books, the author isn't afraid to say "we don't know" when there's a question they don't have the answer to. It's a refreshingly honest feeling book.
January 8, 2015
Fascinating perspective, a view that is very often missing. Amazing how appropriate and applicable ideas from this book are today! Over 25 years later. I wish more people understood the context of programming form the psychological perspective.
April 20, 2013
The occasional interesting tidbit, but mostly truisms and observations on processes that have changed a lot over the decades.
December 2, 2023
Got stuck in the middle of the book. Moving forward became slower and slower. So eventually I decided to quit.
The book is not bad per se. It is quite outdated, but my 25-year anniversary edition was stuffed with the author's comments from 90-s, 25 years after the first edition. It was interesting to see how things worked back in the 70s and what had changed in the 90s (and of course compare it with the situation now, after 25 more years). And the language is quite nice and easily readable... But gradually the novelty dissolved and I just saw the same outdated examples with mostly obvious (now) conclusions. I still found interesting points here and there (that's what pushed me to keep on reading), but eventually, the density of them was too low.
I started to read the book because of the idea of the Egoless Programming approach, which is de-facto a standard in all the modern big IT firms and departments (but not in small ones yet, unfortunately). It was engaging to read about Code Review or Shared Code Ownership as something fresh and new, something that would increase the productivity in future (and it surely did).
In fact, the book touches on lots of major and important topics: programming as a personal activity, programming as a social activity, programming as actually a set of various activities (that require various skills), performance, leadership, environment, and informal processes... and more. But for each of them, this book can be just a starting point, a curious artifact from the prehistoric past.
Yeah... and the title is misleading (not so much psychology inside), but it's a known bug.
The book is not bad per se. It is quite outdated, but my 25-year anniversary edition was stuffed with the author's comments from 90-s, 25 years after the first edition. It was interesting to see how things worked back in the 70s and what had changed in the 90s (and of course compare it with the situation now, after 25 more years). And the language is quite nice and easily readable... But gradually the novelty dissolved and I just saw the same outdated examples with mostly obvious (now) conclusions. I still found interesting points here and there (that's what pushed me to keep on reading), but eventually, the density of them was too low.
I started to read the book because of the idea of the Egoless Programming approach, which is de-facto a standard in all the modern big IT firms and departments (but not in small ones yet, unfortunately). It was engaging to read about Code Review or Shared Code Ownership as something fresh and new, something that would increase the productivity in future (and it surely did).
In fact, the book touches on lots of major and important topics: programming as a personal activity, programming as a social activity, programming as actually a set of various activities (that require various skills), performance, leadership, environment, and informal processes... and more. But for each of them, this book can be just a starting point, a curious artifact from the prehistoric past.
Yeah... and the title is misleading (not so much psychology inside), but it's a known bug.
April 19, 2024
A hard read due to its tedious and long explanations of the actual points.
I found Part 1 and 2 the most insightful, perhaps due to the book still being "fresh" in my hands. It seems to me, from my own personal context, thht relatively little seems to have changed in regards to the psycological nature in humans. One has to, of course, observe a lot more of contextual, social cultural and collective higher intellect to deem this true.
How we read code is very interesting. How we enter a code base and level our contextual mind towards expectancies and follow-through is very interesting. That has also, in my opinion, a lot to do with how we write code. There are constant trade offs, I believe, when we read and write code, and allowing oneself to reflect upon one selfs moving intelligence can help us determine whether we find ourselves in a better position to either read or write code. Look at how you wrote and read code a year ago. And how you do it today. What has changed in you in that time ?
An example in the book is about how Programmers is in the upper bound in regard to having a higher IQ's than "other people". I very much doubt that looking at todays programmers, simply because they don't have to be. Programming has changed from being highly specialised to being somewhat a choice of how "deep in the stack" you wish to go and how the field has been democratized in an economical way - there are programmers everywhere.
The commentarty and the questions after each chapters are highly recommended. Even if some of them are dated, they circle around issues that are still very much true for todays human programming environments.
I found Part 1 and 2 the most insightful, perhaps due to the book still being "fresh" in my hands. It seems to me, from my own personal context, thht relatively little seems to have changed in regards to the psycological nature in humans. One has to, of course, observe a lot more of contextual, social cultural and collective higher intellect to deem this true.
How we read code is very interesting. How we enter a code base and level our contextual mind towards expectancies and follow-through is very interesting. That has also, in my opinion, a lot to do with how we write code. There are constant trade offs, I believe, when we read and write code, and allowing oneself to reflect upon one selfs moving intelligence can help us determine whether we find ourselves in a better position to either read or write code. Look at how you wrote and read code a year ago. And how you do it today. What has changed in you in that time ?
An example in the book is about how Programmers is in the upper bound in regard to having a higher IQ's than "other people". I very much doubt that looking at todays programmers, simply because they don't have to be. Programming has changed from being highly specialised to being somewhat a choice of how "deep in the stack" you wish to go and how the field has been democratized in an economical way - there are programmers everywhere.
The commentarty and the questions after each chapters are highly recommended. Even if some of them are dated, they circle around issues that are still very much true for todays human programming environments.
September 16, 2018
This is an absolutely fantastic book, delightfully written, full of (evidently timeless) wisdom, and with a very poignant epilogue. The end-of-chapter questions and bibliographies are worth reading too.
Weinberg deals with the social and psychological aspects of the craft of programming with both studies and stories, and is always careful to point out where a lack of thought can lead one astray.
None of the software, systems, or hardware discussed in the book are relevant today, but it turns out that the people working with them haven't changed much in the past 40 years.
Weinberg deals with the social and psychological aspects of the craft of programming with both studies and stories, and is always careful to point out where a lack of thought can lead one astray.
None of the software, systems, or hardware discussed in the book are relevant today, but it turns out that the people working with them haven't changed much in the past 40 years.
April 21, 2023
Most of it is really good. Sure, it's a bit dated, but the concepts are timeless and true. I would rate it higher except for the tedious writing style and the irrelevance of the last few chapters. It's a bit of a slog, taking a bit too long to say what needs to be said. The last chapters were so painful and boring, I had to just skip. I really do not want to read his thoughts on what a programing language is, what makes a good programming language ad nauseam, using dated examples. It's unfortunate because his absolute brilliance in human dynamics is worth its weight in gold.
September 20, 2018
- Some chapters are terribly dated because they are very particular to the (long-outmoded) tech of the time
- The psychological literature has moved on in some areas -- note that this predates even Myers-Briggs!
- There are some kernels of good advice and entertaining war stories from the author's consulting career. The general lesson is timeless: computer programming is a human activity and thus is worth considering from a "psychological" (human factors) perspective.
- The psychological literature has moved on in some areas -- note that this predates even Myers-Briggs!
- There are some kernels of good advice and entertaining war stories from the author's consulting career. The general lesson is timeless: computer programming is a human activity and thus is worth considering from a "psychological" (human factors) perspective.
January 22, 2018
Sometimes a bit hard to read as it is more of a scientific report yet written for a broad audience rather than easy-to-read kind-of-self-help bestseller. Some parts obviously obsolete in terms of technology (machines, languages, tools), others (not so surprisingly) still relevant - those revolving around human mind.
September 16, 2018
A bit long, but (perhaps suprisingly) still very relevant, as we still keep repeating the same mistakes as 50 years ago. I expected the Programming Tools chapter to definitely be outdated, but even that one isn't — it predicts TDD, mutation testing, and other techniques that still aren't as widely used as they should be. From the earlier chapters I'd highlight the concept of Egoless programming.
Displaying 1 - 30 of 61 reviews