Bricks and mortar still seem to play an important role in programming, even in a profession where much work can be done offsite.

My preferred work environment happens to be my home. However, even with a good background (linux, java, C, C++), a good work history and a monetary incentive (the lowly Canadian dollar), most companies aren't willing to entertain the thought of a telecommute position.

While communication among programmers is important and our modern communication tools are far from perfect, it amazes me that companies are still so focused on employees "being there" rather being focused on what they produce. They would rather pay for relocation and expensive high tech cubicle real estate and measure performance by attendance.

-- darrell pfeifer, November 6, 2000

I agree with the poster above about reversing the comment about time spent understanding others' code. An excellent resource about this concept is Code Complete, by Steve McConnel. Given that (I forget the exact number, but it is well over 50%) of programming time is spent maintaining or modifying existing systems, what makes a good programmer is a programmer who can write code that is very easy to understand for the next programmer to come along and have to deal with it. Easy to understand code is quick to get up to speed on and is also conductive to fewer defects, because a lot of defects can be caused by a later programmer misunderstanding exacly how the existing code works. Just getting the code to work in an efficient manner is not enough. If it is excellent code, but cryptic, then it will waste a lot of time (and money) later when someone other than the original developer has to deal with that code. If the design is good (perhaps not super-excellent, but gets the job done) but extremely easy to understand, then time (and money) will be saved later on. A single good programmer can probably rambo-code out a system faster than a group of programmers, but that rambo code that saved so much time for the first release will come back and haunt all future releases - completely erasing any initial cost savings advantage in the long run.

-- D Goodkin, November 6, 2000

Another excellent book on managing programmers is Weinberg's "The Psychology of Computer Programming". (Ignore the technology of programming in the book, look at the message underneath.)

One fundamental objection that I have to the thesis of this article is that one must sacrifice all non-work life to the coding at hand. While at a previous employer, they had internal studies and some external studies of hardware and software engineers that showed steady declines in productivity after more than 1 month of serious overtime worked. This was at a site that turned out very large custom systems at the bleeding edge of digital hardware and software capability, with very high productivity (3-5x industry average overall), even with large project teams (400+ engineers). Their key to getting things done was by having a strong systems engineering group that allowed the problems to be broken into manageable chunks so that the staff could concentrate on their chunk and not spend huge amounts of time in meetings. They also sent everyone to training on the systems and software engineering process so you knew your way around. We worked an average of 45-50 hours/week and generated quality code at very high rates.

-- Edmund Hack, November 6, 2000

I would like to suggest a correction to the article:

Mr. Greenspun uses the notion of reinforcement in regard to managing people. Alas, he made a serious error when he used "negative reinforcement". I believe that where he uses "negative reinforcement", he should use "punishment" instead.

While I have a degree in Computer Science, I did take an introductory course in Psychology, and the definitions of positive and negative reinforcement and punishment were well explained. In this context:

Positive reinforcement:
A programmer writes a lot of really good code (behaviour), so you give him a lollipop (the positive stimulus), which you expect will increase the likelihood of that behaviour recurring.

Punishment:
A programmer writes some bad code (behaviour), so you take away his foosball machine (punishment), which you expect will decrease the likelihood of that behaviour recurring.

Negative reinforcement:
You hire someone to lash a programmer continuously (the negative stimulus) until the programmer learns to escape it (removal of the negative stimulus) by writing lots of good code (behaviour). This will increase the likelihood of that behaviour recurring. It is hoped that the subject will eventually learn to avoid the negative stimulus entirely, rather than merely escaping it. :-)

Clearly, both positive and negative reinforcement result in an increase in the frequency of a particular behaviour, but punishment decreases it.

For other information on this, simply visit http://www.google.com/ and search for "reinforcement punishment positive negative" and check out the results.

Yes, I know that this may seem nit-picky, but just as we in the computer industry appreciate it when our jargon is used correctly by those not in it, I'm sure the psychologists of the world would appreciate it if we used their terms correctly.

-- Kevin McGregor, November 6, 2000