How Do You Know A Developer Is Doing A Good Job?
Evaluation of developers is an important topic for anyone involved in software development. Many developers care a great deal about career growth or raises at the very least. Managers need to be able to justify decisions around promotions and raises. 
The complexity lies in the fact that the nature of software development does not make it easy to measure the value a single developer brings. If you have a product that has hundreds of features and makes $10 million a year, how do you know how much of that value was attributed to a single feature? Even if you could do that, the feature was most likely worked on by multiple developers. How do you attribute the contribution of each?
There isn’t a good answer to that question. It just isn’t practical to attempt to make those kinds of measurements. What we are left with are subjective judgement calls by managers.
The risk with this approach is that the criteria are vague from a developer’s point of view. They can’t really know what their manager is thinking. There is now an incentive to focus on learning to sell themselves to their manager instead of focusing on becoming a better developer.
An attractive solution to this problem are quantitative metrics. If we can’t measure the exact value a developer brings to the company, maybe we can find something we can measure easily that will be a good indicator of value created?
The most naive measure here is counting the lines of code a developer writes. This may make sense to those who aren’t developers, at least at first. Developers write code… so maybe more code means more value?
The problem here is that high quality code often means fewer lines of code. A really simple example is: Say you wanted to display 100 products on your e-commerce website. You could do something like this:
displayProduct(1)100 products, 100 lines of code!
displayProduct(2)
displayProduct(3)
….97 lines later…
displayProduct(100)
No decent developer would do this.
They would instead make it 2 lines of code:
for productNumber = 1, productNumber <= 100, productNumber++:If you paid your developers per line of code, you would reward the inefficient developers.
displayProduct(productNumber)
An analogy to this is writing essays, novels, blog posts, etc. Would you judge a writer solely on the number of words written? Probably not. There are a minimum number of words needed to get a complex point across, but those points get lost when a writer clutters their work with useless sentences. I know I’ve read books that would have been great 3 page essays, but ended up being really tedious books.
So the lines of code metric doesn’t work. The notion of a quantifiable metric for evaluating developers is still attractive though.
Some may argue that creating many code branches is the mark of a great developer. Yet I once worked with a developer who would create code branches to hide the fact that he wasn’t very productive.
Some may argue that you can measure the number of code commits a developer makes. But that just makes it more likely to get lots of really tiny commits that have little to no meaningful changes in them. Or a developer can easily game that by undoing and redoing the same few sets of changes to bring up commit counts.
Maybe number of bugs fixed is the answer? Software bugs can be complicated though. By tying raises and promotions to bug fixes, you create the incentive for a developer to fix apparent issues while ignoring underlying causes. It would be like using duct tape to fix a broken leg. Worst case, you would reward developers who don’t take extra care to prevent bugs in the first place.
The real problem with quantifiable metrics like these is that they change the incentive for a developer. While creating business value is the goal, it can be hard for a developer to make it apparent that they are creating business value. It would be much MUCH easier to just optimize for other quantifiable metrics regardless of whether those metrics bring value to the business or not. This is far from desirable for anyone.
We are still left with the challenging question: how do you know if a developer is doing a good job?
In my opinion, the best measures are all subjective:
- Are they good team members?
- Can they solve problems?
- Can they write good code?
- Are they eager to learn?
- Can you trust them?
Quantitative measures are attractive because they are easy. But nothing about management is easy. If it was, anyone could do it.
Do you have an evaluation method that you think is unique? I would love to hear from you!
Hi there! I hope you enjoyed this post.
I keep this blog around for posterity, but have since moved on. An explanation can be found here
I still write though and if you'd like to read my more recent work, feel free to subscribe to my substack.
I keep this blog around for posterity, but have since moved on. An explanation can be found here
I still write though and if you'd like to read my more recent work, feel free to subscribe to my substack.
