Book cover
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."
—Eric S. Raymond
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."
Conclusion
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.
There are comments.