Oh yeah, some responses:

Remember what Fred Brooks said in The Mythical Man-Month: high quality systems must be architected by no more than two people.
-Don't architect your systems. Fred Brooks was right a long time ago, not now. Software systems that are used are never finished: therefor static architecture of software is a mistake. Don't bother designing at all.

Your business success will depend on the extent to which programmers essentially live at your office.
-You're confusing physical and mental presence.

How does one create a good programmer?
Make her work with a great programmer.

What attracts good programmers? Traditionally the best programmers seek the most challenging problems. They want to work in an organization that is trying to build something important.
-They also want to work with minimal interference. Let programmers program.

If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer.
-Early birds aren't good programmers?

Yet managers who are spending a portion of their time designing software or writing documentation are at risk of neglecting their duties to review subordinates' work.
-don't document and don't design. Also, conserve managers.

Our solution is to decouple responsibility for review from responsibility for scheduling review. We use administrative assistants to ensure that each manager is scheduled to look at every subordinate's work at least once per week, more frequently in the case of junior employees.
-if reviewing is good, constantly review. Use programmers to review programmers.

Software engineering companies will tend to have a fairly flat distribution of intelligence. The 22-year-old Stanford CS punk that was just hired will be just as smart as the 30-year-old lead engineer who will be just as smart as the 40-year-old CEO. Within a company's technical team, the raw IQ differences are even smaller.
-if we know that there is a least 10-1 difference between great coders and everyone else, then we know that IQ has little to do with it.

positive reinforcement is more effective than negative reinforcement
does not easily sit with:
But at the end of the day nobody should be confused as to who is providing leadership. There is an irreducible amount of Engineer A imposing his or her design on Engineer B. This can lead to some harsh-sounding words and bruised feelings.
-In discussing the workplace, you neglect to mention psychological comfort.

Suppose that a programmer needs to spend 25 hours per week keeping current with new technology, getting coordinated with other programmers, contributing to documentation and thought leadership pieces, and comprehending the structures of the systems being extended. Under this assumption, a programmer who works 55 hours per week will produce twice as much code as one who works 40 hours per week. -then: learn half as much new technology (if technology moves so fast, half of it won't be worth learning anyway), halve coordination with other programmers, halve documentation time, halve leadership activity time, halve attempts made to comprehend complex systems. Under this reduction a programmer working a 40hr week will be almost twice as productive as one who doesn't. Under this reduction a person who works a 55hr week will be roughly 50% as productive again as one who works a 40hr week. One will actually need to work just under a 70hr week to be twice as productive as someone who halfs their non-code activities. It's obviously more efficient to perform a self-motivated business process reengineerment than double time spent coding.

-- Bill de hOra, November 12, 2000

Programmers dread elaborate process, endless meetings, and layers of marketing approval before a product can be shipped. Ideally it would be possible to conceive a product on Friday evening, set up the development environment Friday night, write code on Saturday and Sunday, test on Sunday night, and ship on Monday morning.

An excellent article that generated a lot of discussion about productivity, work hours and defining "great programmers". However I was shocked to see this gem pass everyone by. In the above scenario even cutting edge companies with great programmers are going to be shipping crap out the door because they neglected to put the hours in testing it.

-- Mark Pawson, November 14, 2000