The Psychology of Computer Programming: Silver Anniversary Edition

Gerald M. Weinberg (1998)
Review date: March, 2013

This is one of these few books that you can read over and over and get totally new insights for every reading. For this reason I didn't even try to write a summary. Of course there are chapters, but I can't summarize their contents in any reasonable way. 

In essence, this book is a study of the programming profession from a psychological point of view. The author applies mechanisms and observations from that domain to expected and unexpected aspects of the programming profession. The book comes in four sections: Programming as human performance, programming as a social activity, programming as an individual activity, and programming tools, and it's within these areas that various techniques and tools from psychology and sometimes sociology (and other human sciences) are applied. In practice this means that the reader gets to learn how cognitive dissonance affects a programmer's defensive mechanisms, that programmers tend to prefer to be managed by people who know their profession really well, and that programming teams tend to live in a constant state of chaos, which means that programmers should be good at handling change. These are mere examples. The book contains literally hundreds of equally interesting findings.

Now, this book has been written in 1971, and pretty much all of its contents are still applicable, at least when it comes to the "soft" parts. As for the technical parts, some sections refer to and contain examples in languages that developers of my generation can't relate to. The intricate shortcomings of the PL/1 language don't keep me awake at night. On the other hand, the majority of these examples are in the first and last section of the book, and what's important in them is the underlying problem, which often enough can be transferred to a more modern language. All-in-all, yes, for readers who are born after 1960 some of the examples may seem alien, which sort of makes you less happy reading some sections, but that's pretty much the only weakness. 

As I've said in the beginning of this review: You probably can't absorb all contents of this book in one reading. What you'll take with you will depend on your current context. When I read it, I was focused on team and leadership issues, so contents treating these topics stuck more. 

For this review I'll reverse the order a little. I'll give the final verdict and then share what I found most interesting. Final verdict: MUST READ. This is one of the few classics on par with The Mythical Man-month. There's so much to be had from this book, and if all else fails, you can still use it as a quote machine. A minor part of it is outdated and irrelevant in our context, but that's just charming. 

Buy it, read it, become a better human being.

Ok, the verdict is issued, now for my personal gems. Quite early, introspection is mentioned. Now obvious or not, in any profession you should engage in it to actually become better at what you do. I'm grateful that someone put that down in writing. Then there's the notion of "egoless programming". A concept being a child of an era when programmers wore white lab coats and scheduled jobs on mainframe computers, it is still the predecessor of the kind of programming we want to do in agile teams: sharing, collective, and cooperative. As it turns out, the foundation for pair programming and shared code was laid 45 years ago. 

Much interesting is said about teams, their goals, how they should be lead, and how their management culture affects the way in which they absorb new members. I really recommend the part about programming as a social activity. 

Another gem is the description of the difference between the amateur and the professional. I'm making a longer line of reasoning short, but it goes something like this: Amateurs are heavily focused on the problem and do everything they can to solve it. Professionals have seen the problem and reflect on how to avoid it in the future. I reread this section at least three times.

I also liked a line of reasoning that lead to the rather intuitive result that programs that are appealing to the eye are also more likely to be correct. Personally I tell people to squint when reading code, and if it looks bad, then it probably is. I'm just glad that an industry guru has his way of saying the same thing. 

The reader will also learn some interesting facts about how the human memory operates and how that affects the readability of a program. Cool stuff. 

Finally, there's the epilogue. This book must have the most dramatic and thought-provoking ever, for being a book on programming (sort of). I don't want to spoil anything, so just read it. 

I could go on and on. What I've emphasized in this review is roughly a quarter of the notes I've made when reading this book, and I'm quite sure that my notes would cover some completely different areas if I reread it. What I want to say is that every reader will find tons of gems in there. 

Who should read this book

Everybody with a couple of years in the profession should read this book. This is a true classic.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.