Insights on an individual developer can be a scary topic. As developers, we’re often understandably allergic to the thought of our work being watched and evaluated. However, we probably also expect to be rewarded for good work, so clearly some sort of evaluation is necessary.

At Swarmia, we’re very aware of the controversial nature of this topic, and we always tread carefully when working with it. But we also believe that we can make the work of both developers and their managers better by surfacing the right, healthy facts about an individual’s work, and leaving out the toxic metrics that could be misused.

In this blog post, I discuss our new feature called the developer overview, which is our take on this complicated but important topic.

Introducing the developer overview

Developer overview aims to answer the question "what has this person worked on?". That’s it. We don’t take a stance on whether the work was good or bad or attempt to measure it, we just show it as it exists. This lets you, who has the most context, draw the conclusions from the information we surface. We feel that this is fair to the developers too, as everyone should be able to stand behind their work.

The view has three tabs:

• Activity provides visibility into the larger projects in your issue tracker that you have worked on. This is good for understanding where the majority of your time has gone.
• Focus provides visibility into the types of work that you have done. Have you spent most of your time fixing bugs or building new features? Again, we take no stance here what is the right balance, that’s specific to your situation.
• Pull requests provides easy access to pull requests that you have authored and reviewed.

We also show a list of people with whom you collaborate the most. For individuals, this is interesting to know, and for managers a chance to ask for feedback from the people who know your work the best.

Explicit non-goals of developer overview

There is a lot of data that we could bring to this view, but have explicitly decided not to. Here are some guiding principles on what we don’t want to do:

• Do not allow comparing individuals side by side. Each developer should be considered individually, as the best teams are often composed of various developer shapes that complement each other.
• Do not expose the code metrics of an individual, like lines of code written or their PR throughput. These metrics are too situational to draw conclusions from, and do more harm than good when evaluating an individual.
• Do not limit the access to managers only. If a manager is going to use this view in evaluating the performance of the developer, it is only fair that the developer has access to the same data.

How to use this view as a developer

There is a lot of useful information here for developers that would otherwise be very hard to discover. Here are some questions that you might answer with this view:

• Have I been working on the things that I want to work on? Let’s say I wanted to work with databases more this year, did that actually happen?
• How can I argue for a raise or a promotion? What were the biggest successful projects that I worked on this year that I can bring up to my manager in our performance review?
• Am I reviewing enough pull requests? If I have opened more PRs than I have reviewed, that might not be fair for my team members.
• How can I learn from my mistakes? What were some projects that didn’t go so well, and what would I do differently now?

How to use this view as a manager

For engineering managers, this view provides an excellent way to reduce your personal bias when evaluating someone’s performance. It’s easy to fall into giving better ratings for people we like without the hard facts about what they worked on.

Some questions that managers might answer with this view are:

• What projects did this person work on? How much impact did they have on the project, and how well did the project go?
• Are they reviewing enough pull requests? You probably want to evenly distribute pull request reviews in the team when possible.
• Who have they worked with the most? You might want to ask feedback from these people too to get a full picture of their performance.

A tool for engineers and managers to align

We hope that the developer overview will enable developers and managers to have healthier and more accurate discussions about their work. You can access anyone’s developer overview by clicking on their user avatar anywhere in the product.

We’re committed to advancing a healthy working environment for developers, and are extremely interested in hearing your feedback on what you like and dislike about this view. Please send us your feedback via this quick form.

New to Swarmia?

If you’d like to see the developer overview and other Swarmia features in action, you can get started with a 14-day trial. Startups with up to 9 developers use Swarmia for free.

Get started today