Are there actually any good metrics that can be used to evaluate software engineers?<p>If you rank them based on # of tickets dealt with, they're just going to take the easier tasks.<p>If you rank them based on # of commits, they'll make a new commit for every line of code.<p>If you try and rank them based on lines of code, then the obvious hilarious thing happens.
Although there may be commonality between some projects, every software project is different, and there is not a list of common good KPIs for “software”. Anyone who claims to have that list is lying to you. As a stranger on HN, I don’t know anything about your project and I cannot make specific recommendations on KPIs you should be using. Instead I would ask your self the following questions:<p>1. What am I trying to achieve, and how do I quantify it?<p>2. Do I have direct influence on what I’m trying to achieve? What can I control that influences my objectives?<p>3. What are my leading indicators to success? What are outcomes that occur, or do I expect to occur, before I am successful.<p>4. How much variability is there on the metrics I’m considering? If a metric goes down, how many interpretations can there be of that result?<p>5. How gameable are my metrics? If a metric increases in isolation, does that mean there is a good outcome?
I'd say grow good managers first and then let them assign tickets properly. Once assigned we can start looking at hard facts such as critical bugs, number and difficulty of tickets, etc.
Best one is still just the good old lines of code written.<p>It’s trivial to both measure and game, so not much time gets wasted trying to figure out either part. If you can’t beat Goodhart’s law, join it.