Reader's Comments

A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded.

This is illustrated by the classic business school article:

Kerr, S., 1975, "On the Folly of Rewarding A, While Hoping For B," Academy of Management Journal, Vol. 18, pp. 769-783.

It represents exactly what you are saying.

-- Tyler Pruett, October 30, 2000

Philip, your ideas on rewarding programmers are excellent. However, I don't believe number of hours worked defines a good developer. Programmers get older and have families. Saying that they have to log a certain number of hours in the office is stupid, almost like IBM counting programmer productivity in "K-Locks" (thousands of lines of code).
A good developer can often finish what an average one can do in half the time an average developer can - with less bugs and with better documentation.

A couple of good books on this topic include,
"Software Project Survival Guide by Steve McConnell"
(Somewhat dry - but good reference book)
First, Break All the Rules : What the World's Greatest Managers Do Differently
(Not one of the typical management books - this one has some actual research behind it.)
Microsoft Secrets : How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People
(A few good chapters worth reading)

-- Anthony Barker, November 6, 2000

... the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers

I would argue that the phrase above should be reversed: ".. the good programmers will consume nearly their entire work day just in reading and understanding code generated by the average programmers". If the programmer is good, the code will be elegant, easy to read, and practically self-documenting (not that that's necessary because the good programmer would have also written lots of clear concise comments as well). Average programmers will make a mess of the design and would take anyone more time to figure out what the heck they were thinking.

-- Dion Loy, November 6, 2000

---

anterior

próximo

---