I found this book very helpful, in that it gave me a fresh picture of how life could be inside a high-tech organization (Info Tech in my case). Very accessible, in contrast to all the tech manuals I had to read. ( )

Useful book, back when I was in the trade. Maybe more about management than I cared to know, but it did reaffirm that programming, well done, is a creative activity, and the importance of planning ahead. ( )

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.
( )

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. ( )

.
.
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 ( )