Measuring whose software engineering is bigger

My last manager at Microsoft measured engineers by the number of checkins, they did. He said, "I want every engineer to do at least two checkins per day." And I also met a manager, who went even further, saying, "If regular Joe does one checkin per day, then I expect a senior guy to do three and principal (staff, guru, whatever) ten!"

Such a simple arithmetic (or geometric) way to measure seniority: seniority = ln(checkins per day)!

It's almost like 16 years old thinks about sex. "Ok, I am too young, so I have nothing, and older guys with questionable abilities, they'll pull once a month, and some regular Joe would do once a week, and when I grow up, I will be a real stud and I'll do that every day... twice, and three times per day on weekend, and Superman probably did that 10 times a day!"

And only once you start meeting real women, you learn that quality matters much more.

Technically, if you have simple enough project and junior developers, it's probably possible to use metrics like that. Just like 16-years-old metrics on sex may be applicable in a brothel. But with serious work, you may want to check against something more substantial. Ideally, the amount of money brought or saved for the company.

How do I change situations in which I cannot work effectively as a professional programmer?

Just got my copy of "Understanding the Professional Programmer" by Gerald Weinberg. Bravo!

"Some of the methods that the professional programmer should be working on are these:

1. What should I do about a program for a well-defined problem that I don't believe should be solved at all?

...

5. How do I work effectively with people whose problems are not well defined, who don't understand as much about computers as I do, who understand more about many other things than I do, and whose motivations are different from mine?

6. How do I change situations in which I cannot work effectively as a professional programmer?

...

9. How do I work on those aspects of my own personality and problem-solving approach that are so personal I can't even see them, even though they may be the most important factor in my effectiveness as a programmer?"