The only objective and repeatable metric of programmer productivity is if a single programmer is assigned the task of delivering a tool or component, from scratch, by himself. His productivity is the inverse of the time to delivery.
This excellent insight takes us to a place where productivity is even harder to measure: How does one measure the value of a piece of software? Software that has subtle bugs flying under the rader of our test suite has some kind of negative value. Software that lowers the "productivity" (however we measure it) of future programmers who need to extend or change it has negative value associated with it. How do we measure that?
Imagine the exact same formally specified requirements handed to four different programmers:
The first programmer, "Ned," does the job in a straightforward fashion, and delivers working code passing all tests.
"Fred" does the job using uncommon techniques (parser combinators, for example) in less time and produces less code.
"Ed" proposes that if some of the requirements are relaxed, there is an open source solution that can do the job with trivial integration.
The last programmer, "Jed," sees some commonality with some existing code and proposes that the scope be expanded to produce a new piece of infrastructure (message queues, web services, SOAP, &c) solving a more general problem.
Fortunately in the real world such situations never arise except at a few exceptional companies. At most companies the difference between the top and bottom developers is very noticeable.
Ned would have to help Jim with his work because Jim is really not qualified to be employed as a developer, but he eventually accomplishes the bare minimum by using a lot of other people's time. There are probably a couple Jims and a few more people who accomplish the bare minimum if given enough time. Then you have Bob who, every sees as some kind of hero because he works 10 hours every day and "finishes" a lot of work. Unfortunately most of Bob's work requires constant maintenance, often by Bob. Somehow this makes Bob seem like more of a hero.
Most developers are aware of who on their team is more productive even if they cannot quantify it.
I'm convinced the only real-world metric that matters is "how much other people want to work with you". Being an easygoing, fun person facilitates that dramatically.
I think this is true up to a certain point, then stops mattering. Once someone is at the 'pleasant enough to be around' level, I'd much prefer he/she be more intelligent or skilled than more fun if we're working together. This is partly because lower key, quieter, more intelligent people can often turn out to be more interesting and fun in the long run than people who have great social skills and confidence but less depth in their thinking and personalities.
If we extend "fun to work with" to include "quieter, more intelligent" people, I think palish's definition may work rather well. That group definitely falls into "people I want to work with."
Weirdly enough, I just finished reading about how NBA players overwhelmingly wanted to play with Bill Russell over Wilt Chamberlain, as part of an argument that Russell was the better player.
All (but not only) people with good people skills and zero productivity would be motivated to say this.
Edit: I think I might have misunderstood what palish meant by "By how fun they are." to exclude productivity and focus entirely on personality. My mistake, if so.
That might be true in the very short term, but in the medium- or long-term, no one actually enjoys working with "fun" people who have zero or negative productivity.
In which case you join me in disagreeing with the statement that 'the only real-world metric that matters is "how much other people want to work with you'."
Okay, fair enough. I shouldn't have taken that sentence out of the original context, which said "By how fun they are." Or maybe I just totally misunderstood palish's point; actually rereading, that seems more likely than not. Apologies.
We can't judge them in a vacuum. What is the rest of the team like? Are they all of the same mindset as Ned? Can they understand Fred's code? Which requirements did Ed relax and what is the quality of the open source code? Does what Jed suggested make sense?
In my experience, programmers' competences aren't so broad that we can take the decisions you presented. Repeatable measures are easier when there is a repeatable conventions to deliver work.
IOW, either I'm supervised by someone that should know relative merits, or I'm judged by the final results. In either case, I'm not paid more, because I believe that the real value is more on errors I prevent than in lines I write.
In my experience, programmers' competences aren't so broad that we can take the decisions you presented.
Are you suggesting that in your experience, programmers never use unusual techniques, never push back on requirements, and never engage in refactoring or infrastructure construction?
Repeatable measures are easier when there is a repeatable conventions to deliver work.
If wishes were horses, beggars would ride. Sure it's easier when there are repeated conventions. But are there actually repeated conventions? You could create an environment with repeated conventions by firing Fred, Ed, and Jed. Now you can measure everything with ease. Are you better off?
In my current job my boss has much control over my work, he is happy with my performance, he knows that I'm way over average, but (please, believe me on this) he's powerless to improve my situation.
In other jobs I've been much more autonomous, performed much better than now, but there was nobody that noticed it, because there wasn't anyone to compare to, bosses didn't really understand what I was doing (just that it worked) and specially because they didn't know what could have gone wrong and I made right.
Time ago I was in a different environment. I was in an intermediate situation. My autonomy was limited, but not so much. Bosses were very experienced and knew how difficult my work was. I got raises and a promotion. Then I was better off, and I'd say so was the company..
Which is the elephant in the development room. IMO, maintainability is exactly what good programmers should be judged on. Any programming project of any meaningful size and usefulness will spend at least an order of magnitude more time in maintenance and enhancements than in initial development. For the largest projects (Google, Facebook), maintainability becomes 1000 or more times more important than the original development time.
Problem is, you can't quantify maintainability. What a good programmer contributes to maintainability and enhanceability is the absence of certain problems or classes of problems. Everything from choosing an exotic languange that nobody else can maintain, to the choice and organization of source control. We take that sort of thing for granted in HN type projects, but problems like "nobody knows how to compile that" are a really big problem at corporate enterprise scales, especially companies that are not fundamentally technologists, say finance or medical or shipping. An individual programmer is more likely to incur reward if he looks like he's playing the hero in a bad platform and ecosystem ("only this guy has the wizardry to manage that!") than if he built a good understandable platform in the first place.
Very true. A friend of mine, who worked for a very large company at the time, once described the perfect system for achieving recognition as a developer. Firstly, write code that's full of bugs and is hard to maintain. Secondly, once the code is shipped and starts going wrong, make sure you step up to the plate and fix all the bugs that you created. That way, you get kudos for delivering code rapidly and for all the customer support work you do. Contrast that with the guy who writes good quality code who doesn't ship as rapidly and who doesn't have half as much customer contact.
I don't have the citation on hand, but this goes along with a study I read about customer loyalty. Customers who have a problem which is promptly corrected by the company are more loyal than customers that never have any problems.
I think that makes a lot of sense - relationships build loyalty and trust (as long as they are positive in nature). Buying something and never interacting with the producer doesn't build much of a relationship - it's merely a transaction.
I think there's an awful lot of truth in that. You could make the argument that customers of Enterprise Software (that we love to deride) are not paying for the awesome quality of the software so much as for the assurance that the company will pull out all the stops to support them if anything does go wrong with the software. On a psychological level, that leads to a good relationship. On a practical level, that means that the customer is paying not for a great experience when things are going well but for a good experience when things go wrong.
Unfortunately employers (myself included) like to have different programmers working on different tasks, where it can be difficult to measure non-equivalent tasks.
I'm not sure I agree with this. Granted good design takes some extra work. But for the most part, in my experience, coders who write bad code also do it slowly (perhaps because they don't understand it), while those who write cleaning code are able to move more quickly. As a project grows, you have to refer back to your own work more often. The price for poor code starts to be paid almost as soon as the cursor leaves the page.
Productivity is a factor of efficiency and effectiveness. Efficiency being the measurement of how fast things get done, and effectiveness a measure of how well things get done (meeting the requirements, including all features, number of bugs/issues that crop up, quality of code).
This is essentially the same thing you are saying, just broken down. Still, it's difficult (not impossible) to measure one programmer against the next in terms of productivity. Using these metrics it is quite possible to measure a programmer against himself over time.
The problem is that measuring the necessary factors affects the level of productivity being measured.
"This is essentially the same thing you are saying, just broken down."
Actually, I took his meaning as productivity being only a measure of how fast the work gets done, your efficiency, and not of how well the code is written, your effectiveness.
His comment: "And that doesn't take into account maintenance.", implies to me that code quality is not a factor.
Unfortunately, this is the measure that seems to predominate, especially with non-technical managers. If it takes twice as long to do it right, all the non-technical manager sees is that it took twice as long. The subsequent reduction in maintenance time and cost from doing it right doesn't seem to get noticed.
Of course, the ideal is to get the job done fast and right.
So much of it comes down to managers not being able to tell good code from bad. If you look at quality as a crapshoot (it's genuinely hard to tell architecture astronauts from good code) then indeterminate quality quickly beats indeterminate quality slowly.
And that doesn't take into account maintenance.