Formulating developer metrics is kind of like writing HR regulations defining sexual harassment; it certainly can be done, but you can’t phrase them in entirely

Formulating developer metrics is kind of like writing HR regulations defining sexual harassment; it certainly can be done, but you can’t phrase them in entirely in reductive terms. E.G. compare: “Employees should not stare at their colleagues in a demeaning way or in a way which makes them uncomfortable.” With: “Eye contact should not last more than 1.5 seconds, and after finishing a conversation, an employee may not continue to look at another employee for more than 2.5 seconds.” The second sounds so very much more objective and measurable, but is unworkable in practice and in fact doesn’t actually rule out harassing looks—-any more than stipulating that a programmer crank out at least 100 lines of code an hour will rule out programmer slacking. The trap is conflating “objective” and “measurable” with being expressed in a reductive language describing actions which can indeed be objectively measured, but which bear no essential or logical connection with the way programmers deliver value. I once made a 10 minute hack which saved our company $50 million dollars. I’ve also worked 80 hours a week for 11 months on code which was ultimately just thrown away. Most companies I have worked for have had an end-of-year rank-and-yank-style of programmer performance review process which soaked up MONTHS of management bandwidth. It’s certainly annoying and inconvenient, especially if you do need to tap your manager for a substantial amount of help during that time, but on the other hand, there is something reassuring in the thought that evaluating our performance is something which everyone realizes needs a lot of discussion, negotiation, and TIME to see what the longer term impact of our efforts are.