I'm completely with you on that. As for an example where some metrics might be useful: some form of complexity measurement of the code helps a new developer on

I'm completely with you on that. As for an example where some metrics might be useful: some form of complexity measurement of the code helps a new developer on the team discover where to poke to find out issues, as well as which parts are critical. While far from perfect, it gives you a starting point that's possibly better than "randomly open files in project". Now, this comes with interesting points: - the metrics in this case are in the hands of the professional in the field - the metrics are there to serve the person itself, without affecting others Metrics on commits, line of code, tickets closed are useless from my point of view. If you ask in a developer team who is weak at the moment (assuming there is no room for improvement is stupid) gives better results. A decent programmer is able to spot fake ones and is able to notice performance difference over time (not perfectly, but definitely better than metrics). Not to mention, I would be surprised if none of the team would start complaining if someone is doing no work and still getting salary. You can spend an entire day teaching your team something important about the project you are working on, have no commits about it. Or you can use half the day walking around thinking how to solve a bug. Not a single line is written, but that's how some problems are solved. I started counting in my working hours even when sometimes I wake up in the middle of the night and my mind solves programming problems for 1 hour (let's say). I have a decent employee, being at my desk typing is not what I'm paid for, I'm paid for solving problems with software engineering to the best of my knowledge.