How to measure and improve internal developer experience

How to Measure and Improve Internal Developer Experience

Posted in

Most APIs are not public-facing. 58% of APIs are private, found the 2023 Postman State of the API report. So, how can we ensure our private APIs work to their full potential?

Increasingly, many companies are creating dedicated developer platforms. For instance, LinkedIn’s developer insight hub offers several metrics and dashboards for measuring both developer productivity as well as satisfaction. Spotify’s Backstage platform is designed to streamline developer experience, allowing developers to push 2.3x more code to GitHub while reducing cycle time by 17%.

Improving the internal developer experience is a win for all parties involved. It lets developers work smart and hard while keeping project managers informed about what’s happening. This allows a team to focus on what’s important, allocating resources for products and services that get used a lot while improving resources that need extra attention. Below, we’ll consider five tips for improving the developer experience and how these strategies can positively affect your internal API initiatives.

5 Tips For Improving Internal Developer Experience

1. Identify Problem Areas

When you first begin optimizing your internal developer experience, it’s wise to conduct a survey so you can assess your organization’s strengths and weaknesses. The first step is to get an accurate assessment of the problems the development team is facing.

Ask your developers what prevents them from being productive. Is it a lack of the right tools? Too much time spent onboarding new ones? Do lags in communication limit productivity? Each of these insights has a practical solution. The answers should provide a roadmap to follow on your journey toward improving internal developer experience.

2. Pick The Right Metrics

Knowing what metrics to measure is integral for optimizing internal developer experience. You need a clear picture of your current operations and an accurate assessment of the changes you’re making. Picking the right metrics is essential for both.

Cycle time, which is how long it takes from the initial commit to deployment, is a handy metric as it can illustrate both productivity and developer experience. Longer cycle times mean less productivity, but they also mean higher levels of developer stress and frustration.

The size of pull requests is another useful metric to keep an eye on. Larger pull requests mean more complex changes to the code. This also means longer assessment periods, as those changes must be reviewed. The number of pull or merge requests can also offer valuable insights into the developer experience. More merge requests over shorter periods could mean developers are less tied up with busy work, making them freer to be more innovative and creative.

Measuring works in progress also offers insights into your team’s productivity. Most obviously, it lets you know what all they’re working on. It’s also an important metric for employee satisfaction, though, as having too many simultaneous projects can result in feeling stressed and overwhelmed, leading to higher levels of dissatisfaction.

Hours worked on the weekend can offer similar revelations. If your employees are clocking in on the weekend, that’s a good indication they’re feeling overworked.

3. Optimize Debugging

There are few things developers like doing less than debugging code. According to TechRepublic, 26% of developers would rather pay bills, and 21% would instead go to the dentist than spend their time debugging code. The slow, tedious process of debugging code line by line means many bugs get overlooked, resulting in buggy code making its way to the marketplace.

It’s to everybody’s benefit to implement an efficient debugging platform and process. Your developers will get to spend their time on things they’d rather do, and your customers will get a better end product.

4. Shorten Feedback Loops

Keeping feedback loops as short as possible is one of the easiest and most effective ways to improve your internal developer experience. It lets you continually assess that you’re on the right track and that you’re spending your energy and resources wisely. You just need to ensure you have a system in place.

Without a proper feedback system, you may have to undertake an extensive evaluation, like doing a quarterly system-wide assessment. This can take quite a bit of time and be very labor-intensive. It’s not nearly as effective, either, as developers are providing feedback on a task from months ago.

Putting a real-time feedback system in place eliminates all of that, though. It lets you address problems almost instantly, almost as quickly as they start. This also prevents developers from getting frustrated or wasting time on dead-end projects, which is bad for morale and productivity.

5. Eliminate Distractions

Researchers from the University Of California, Irvine report that it takes the average person 23 minutes to get back into a state of flow and productivity after an interruption. It’s vital for both your productivity and your developers’ well-being to keep distractions to a minimum, if not eliminate them entirely.

Enabling asynchronous messaging is one way to reduce distractions, as your development team won’t be pulled out of what they’re doing to focus on real-time communication. Keeping meetings to a minimum and making sure they’re streamlined is another. Make sure you’re scheduling them intelligently, too, so your workers can get back into the groove once they’re finished.

Final Thoughts On Improving Internal Developer Experience

One downside of private APIs is that you never benefit from market feedback. Customers can be an excellent source of insight, as can public users. When APIs are entirely internal, however, you never get that feedback. Putting a system in place helps fill that need, so you still have a continual feedback and improvement loop.

Private APIs themselves are an important component of a positive internal developer experience. They increase collaboration, eliminating silos and diminishing downtime. They drive asynchronous communication, letting your development team focus instead of constantly being derailed by distractions. Most importantly, an internal API-first strategy with forethought helps your team feel appreciated and like their work has meaning, which is vital for everybody.