So you’re responsible for one or more developers?

Of course you want to know how well your developers are performing. That’s perfectly understandable. So now you’re looking for some metrics you can use to measure their performance.

This is where you’re going to have problems …

First of all, this post is mostly directed at people that have never held a developer role (or perhaps have, but it was a long time ago, and they’ve pretty much forgotten what it was like, or the world has changed a bit since then). If you’re a dev yourself, or have been recently, I’m thinking you’ll probably just pretty much nod your head at most of the things I’ll be saying here.

What you need to understand about developers, is that they essentially spend their days creating and maintaining alorigthms of greater or lesser complexity. This of course means they know full well how to manipulate them. If you give them a metric they think is not fair, they will optimise their work around that algorithm, which could potentially be much worse for you than if you just left them alone to get on with things.

Let’s have a look at some common metrics …

Lines of code

What non-developers often don’t understand is that “large change” is not the same thing as “complex change”. Some of this will depend upon the complexity of the codebase (or the overall architecture) that the dev is working with, and will be entirely out of their control.

What looks to be a “simple” one-line bug-fix may have taken days of work and testing to track down (hopefully not … hopefully you have some decent error tracking and APM tools in place to help, along with decent CI/CD pipelines, and you’ve always given devs enough time to refactor as needed and keep the test suites up at a reasonable coverage level, right?). If you measure a single line of code and see it took 3 days, then translate that into poor productivity on the part of the dev, then you’re going to drive your devs away.

This metric will also drive all your devs to look for the easier solutions that they know require more boilerplate code. It may also lead to pointless refactoring to bring up the count. (Sidenote: refactoring is good in general, but pointless changes just to up the count for lines of code change should be avoided at all costs, it just makes looking for things in the change history more difficult).

Number of commits

This one can be reduced to the same as lines of code, since a commit can be any size. A dev could in theory create a commit for each character change in the code.

Number of PRs merged

Again, the complexity of a PR can vary wildly. A larger PR could be (unnecessarily) split into multiple PRs as well to make it look “better” as far as the metrics go.

As with lines of code, this will also drive devs to look for the “simpler” problems that they can knock off quickly, and if you have a lot of stuff in the backlog it can mean that the more complex issues (which may make long term development much simpler) get avoided because the devs are afraid of looking bad when they take too long.

Number of tickets (usually Jira) closed

Pretty much the same issues here as measuring the number of PRs, only you’ll probably also find devs raising multiple Jira issues and bugs when one would suffice, just so they can close several in the same week.

Number of code reviews or time to review

As with everything, a code review can be more or less complex. Smaller, incremental changes are obviously better, but this is not always possible or sensible. Pushing devs to do more reviews will lead to slipshod reviews and the standard “LGTM” (“Looks Good To Me”) on larger ones, becuase they don’t feel they’re being given time to do it properly.

Hours worked

Really? Would you like to measure our bathroom breaks as well, or how much time we take grabbing a fresh coffee?

OK, so how should you make sure your developers are actually productive?

Well, for starters, you hired them - or at least somebody at your company did - so you should start from the assumption that they are doing their best. Some days their best will be more than other days. Some days their best might be just thinking about a complex problem and trying to work it through to a decent solution - they may do most of this on paper and not write a single line of code.

That said, of course there are times when a developer is not productive. This may be for personal reasons (stress, illness etc.), or it might be that they have simply tuned out at work due to boredom, or what they percieve as a toxic work environment. It’s obviously important to spot these cases and try and turn them around.

Know your developers

The easiest way is to talk to them on a regular basis, and I don’t mean the daily standup or scrum retrospective. I mean talk to each of the developers on their own. Have a 1-2-1 with them every other week, or once a month to catch up. Ask them about what they’re working on, how it’s going, what the challenges are in the team, and whether you can support them with anything.

If you suspect a dev is just coasting, talk to them. Find out if there is a problem. Perhaps they’ve been handed a large task and are a little out of their depth and afraid to ask for help. Perhaps they’re going through a messy divorce, or a family member has just died. Perhaps they’re fighting interal bureacracy at your company trying to get something to happen elsewhere that they rely on for their own change (you’d be amazed how often this is the case!)

Some issues may get raised in a daily standup or a retrospective, many won’t. Even work related problems. Often developers have tried to flag issues many times previously and they see that nothing changes, so what’s the point of continuing to bring them up? Better to just accept it and work with the system.

Provide the tools and support they need

I mentioned earlier about tools like APM, error logging, test suites, CI/CD etc. If you’re not using these things (and more), you should be.

If you want your developers to be productive, the number #1 best thing you can do for them is to make sure there are tools in place that can take care of all the edge stuff that isn’t development, that they would otherwise need to do themselves.

Do you have a manual release process that takes half a day for a single resource to do, working off a complex checklist? Look into implementing a continuous delivery pipeline.

Do you frequently get new bugs in production after a release? Look into your test processes. Allow the devs time to create automated test cases for new code and when bugfixing. Implement this in a CI/CD tool as well so it runs automatically.

Do seemingly simple things take days to implement or fix in a specific area? Sounds like your system might be in need of some refactoring. Gather some devs that know that area and ask them for ideas. Allow time to do this refactoring.

A happy dev is a productive dev

The long and short of this is: developers are people too.

Developers are people too!

Most of us will do our best on a daily basis. Some days may be less or more productive than others. This is because we are human. Sometimes we sleep badly or there’s life stuff happening that distracts us. Overall though we generally want to do a good job.

If you want to keep us productive, keep us happy. Remove the pain points - those little tasks where we mutter to ourselves “damnit, I’ve got to do X again before I can fix this thing…”. Make sure there are decent processes and tools in place to support us in our work and help us find bugs and build new features.

If we can focus 90% of our time at work on actual development and not the bits around the edges, it’s unlikely you’ll have any cause for complaint as far as productivity goes.

Under no circumstances …

  • Force install key/mouse loggers on your devs laptops to make sure they’re typing/moving the mouse regularly.
  • Force devs to work with the webcam on so you can check in on them if they’re remote.
  • Anything else that falls under the heading “Creepy AF” …

These things are toxic, and you will run out of good developers very quickly because they will quit and go and work elsewhere.

One BIG thing you can do though …

… and at enterprise level companies this can be more difficult, I understand that.

Let developers have control over their own development environment. Don’t lock down their laptops and tell them they can’t install things themselves. Don’t force a specific IDE on them or say “Docker isn’t approved, sorry”, or “WSL is too risky” (yes, this happens!). Let them work the way they work, because that’s how they’re productive.

I get that your non-tech-savvy CEO might click on that link in a phishing mail, but frankly, killing your developers productivity because you’re terrified of an attack is not the way to go. There are plenty of tools you can use to keep things safe and still allow devs the leeway they need to work well.

Attributions

Header image by Azamat Esenaliev