Fluff article that's mostly rehashing things that people kept trying to implement as metrics in software teams ever since the 1970s -- and failed every single time, as evidenced by the fact that people are still searching for reliable ways to gauge programmers.<p>- Counting stuff does not work. People will stop doing atomic commits and will start pushing 1-3 lines of code or config all the time. Or will start breaking the issues into much smaller ones so as to seem like they are closing many of them.<p>- Verifying means trying to engage more of a resource that's already precious and stretched thin i.e. engineer attention and time. You will end up squeezing your already strained people even more unless you hire extra.<p>- Valuable, okay, but short-term or long-term? I met plenty of "valuable driven engineers with a can-do attitude" whose code I had to fix months later because the product development has ground to a halt. Who's more valuable, the person who makes a customer demo possible that pays $1M one-off investment after the demo, or the person who makes sure the customers with really deep pockets will get their features and start paying $500k a year? <i>(Both are valuable and this was obviously a trick / trap question. Point is, you can't only worship the former group and claim the latter is less valuable.)</i><p>- Individually attributable is a solved problem. Just count commits + coding lines and judge by that, if that tickles your fancy. Everything else does require the attention of other engineers which is not an efficient expenditure of time and energy.<p>---<p>I'll give you one good KPI: make your programmer happy. Recognize that not all work is glorious because they do recognize that as well BUT periodically give them space and time to go off on small adventures to f.ex. optimize a hot path that's proven to be slower than what's deemed productive, or allow them to automate a process, or write a small library that can be reused between teams, or help engage with others who use their code and are unsure how to do so; things like that.<p>Programming is a very mentally straining job. Help these people not hate their job. There are many well-documented ways to keep employees happy.<p>Trying to measure everyone will never work until it gets fully automated, at which point it would be unproductive and illogical to do so -- because if you have such a smart automation then why don't you use it to get your actual work done with it, and not measure your inefficient flesh bag employees?<p>In a nutshell: by the time you get to being able to gauge programmers in a fully automated matter, you would likely just "hire" a bunch of robots and fire the humans.