The book The Psychology of Computer Programming by Gerald M. Weinberg has been on my wish list for a while, ever since reading the cathedral & the bazaar by Eric S. Raymond, in which he talks about how working using the open source approach can not only work on small-large scale projects, but how it seems to be the best way software developers can work together, from disparate parts of the world.
Eric cites the book The Psychology of Computer Programming, saying:
"Gerald M. Weinberg's The Psychology Of Computer Programming (New York, Van Nostrand Reinhold 1971) introduced the rather unfortunately-labeled concept of egoless programming. While he was nowhere near the first person to realize the futility of the principle of command, he was probably the first to recognize and argue the point in particular connection with software development."
Having requested the book as an xmas gift, I finally had a copy of the silver anniversary edition (published back in 1998). The original edition was published way back in 1971, but do not let this put you off, as the ideas and experiences are still as relevant today as they were, way back in 1971.
This is not a long review of the book, more a recommendation to read it if you are a programmer or a manager of programmers, as it may probably change the way you program and interact with other programmers, and can make you a better manager.
He tackles many issues in this book, focusing on the human side of being a programmer. If you have worked alongside other programmers or managed a group of programmers, you will find yourself nodding your head at so many stages in this book. He highlights why teams work or do not work well together. Why some managers are hopeless and others excel, and what we as programmers and managers can do to improve our jobs and working environment, so we can hopefully think differently and understand more about what we do, and why we do it.
Some highlights for me include:
In chapter 5 "The Programming Team" he talks about managers and leadership and how dealing with higher management can be problematic and strained, but good managers understand that results will be far more easily obtained if all the team is on-board and each team member has full participation.
On dealing with upper management:
"he must be willing to stake his position as designated leader on the strength of his professional judgement".
"One of the paradoxes of leadership is simply this: only the leader who is ready to step down has a real chance of success."
In chapter 6 "The Programming Project" he talks about how teams work together, and if a manager wants to have a stable project/team, touching on the egoless programming idea.
"If a programmer is indispensable, get rid of him as quickly as possible."
He also observes the gender inequality in programming teams, when women are part of a team.
"Each prejudice has its price. In a programming project, the exclusion of anyone from any position on any basis besides lack of competence robs the project of the best possible performance. Moreover, once one faction begins to feel that they are being judged differently from others, they will begin to act differently."
In chapter 11 "Programming Languages" he talks of the drive to improve programming languages to be more natural, less complex.
"It is a psychological difficulty which prevents us from writing our 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."
He goes on to talk about some principles for programming language design:
"Programming is not a branch of mathematics, it is a unique form of communication in which human beings take an active role and machines often a passive one."
Each chapter ends with questions for managers and for programmers, to analyse your own situation, and how the issues discussed have affected you.
I came away from reading this book, recognizing many aspects of it in my own programming career, and how even though computer terms and languages change, humans act the same as they did back when the first edition came to print, and there are some valuable lessons to be learned from the issues highlighted in the book.
I recommend this book not only because it was an enjoyable read, which allows you to spot and identify situations you may find yourself in, but how you can change your approach to working with others and how you can improve as a programmer as well as a manager.