Recently 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.
Even though a lot of content in the book is still relevant today, some things were horribly oudated. At some point, the author describes the utility of having conversations with other programmers whilst waiting in line for the computer operator to run your code. I sincirely hope that no one programming in 2019 has to go through the ordeal of handing over punch cards. :)
some take-aways
Here are some of the things that I’ve highlighted throughout the book. If you’re interested in seeing all of the highlights, they can be found on my goodreads page.
We shall see how the individual lends his individuality to his program and how programming lends shape to the programmer herself.
This is a timeless idea. When working in a large codebase, often just by looking at the code I can tell which one of my colleagues has written a certain piece of code. There is unmistakingly a coding style that you can tie to people. With the power of machine learning, even machines can trace who wrote a piece of code. This WIRED article has more info on that.
The other part where programming shapes a programmer rings home with me as well. Programming does shape the way you think about the world and teaches you a way of thinking that can be extended outside of programming as well.
(Someone should definitely study the depressing effect that the all-too-common half partitions have on programmer productivity. They manage to cut off all useful communication while permitting all disturbing sound and movement to penetrate.)
This was given as somewhat of a side-note, hence the parens the author used. Nowadays, we don’t even have half-partitions anymore! Personally, I’d choose the half-partitions over the completely open office. It’s sad to see that in almost 50 years, we still haven’t introcuded a working space that enables people to be as productive as they can be.
the ideal team would be chosen as much for interpersonal skills as programming skills (…)
A lot of the coding tests at [BigCo] focus on solving technical problems. Personally, I’d rather work with a 1x engineer with good soft skills rather than a 10x engineer who can’t communicate. If you’ve ever worked in a dysfunctional team, you’ll feel how important interpersonal skills are. In the end, programming is a team sport so if you have a dysfunctional team, how can functional programs come out? :) (Ideally, take a 10x engineer with interpersonal skills!)
Even when there is nothing else to do, doing documentation is never a voluntary alternative.
It makes me smile to think that half a century ago, no one wanted to write documentation either. This could also help explain why documentation often ends up being outdated or bad. But to shamelessly quote Dick Brandon” “Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing”.
Conclusion
I’ve enjoyed reading the book a lot, as the title should hint at, it talks mostly about interpersonal activities and issues that arise from the field of programming. It still makes for great reading decades after it was published and I expect it to hold up for a few decades more. I, for one, would definitely be interested in reading a similar book adjusted for modern times. Though, I did enjoy the historical perspective given in the book as well. Having not lived through those times myself, it is interesting to see the kind of issues that arise when working on a mainframe with punch cards, in a time when computing was understood even less by the average user than it is nowadays.