8 Proven Ways to Improve Developer Productivity

The quest for ways to improve developer productivity matters a lot, for individual contributors and managers alike. As a leader, you want to get the best bang for your buck when it comes to your developers' output. As a developer, having a keen interest in maximizing your productivity is vital for maintaining high employability and marketability.

But how to improve developer productivity? Answering that is this post's mission. But first, let's define developer productivity.

What Is Developer Productivity? Some Good and Bad Metrics

Developer productivity is the measurement of how efficient software developers are in producing output. Improving developer productivity is of paramount importance for companies, since the performance of a team can often be the difference between being first-to-market or going out of business.

You can't improve what you don't measure, as the adage goes. So, in the saga of developer productivity measurement, many metrics have been proposed. Some are OK, others are terrible.

Let's list a few of the bad ones first:

• Lines of code. It encourages developers to simply write more code, increasing the complexity of their solutions and the surface area for bugs, as well as creating the need for more future maintenance work.
• Number of commits/PRs. It can have a good side of encouraging more granular commits and PRs, but ultimately it doesn't ensure greater output.
• Velocity (for agile) teams. The number of story points delivered by teams shouldn't be used for comparisons across teams, because story points are highly contextual and don't make sense outside of the context of a team.

Can you see a common thread across the metrics above? They're all easily gamed. If such metrics are tied to financial incentives, such as bonuses, then the stage is set for the metrics to be gamed.

Conversely, good metrics include ones that don't encourage toxic competition between developers, contribute to the higher quality of the product, and aren't easily gamed. These include code quality (which can be at least partially measured by static analysis tools), cycle and lead time, and customer satisfaction.

Factors That Impact Developer Productivity

Factors that harm developer productivity include, but aren't limited to:

• Constant interruptions aka context switching
• Inefficient workflows with lots of idle time
• Subpar tools (e.g., slow laptops, slow build servers)
• Lack of access to needed tools, such as IDEs
• Lack of access to learning resources
• Manual execution of routine tasks

8 Ways to Improve Developer Productivity

1. Reduce Interruptions

It's been demonstrated by several studies that interruptions harm productivity greatly. One of the most famous studies concludes that interrupted workers conclude their tasks faster because they compensate for the interruptions by working at a faster pace and producing less, and that comes at a price of great stress and frustration.

How to reduce interruptions in a software development context? Here are some practical tips:

• Embrace asynchronous communication. Use newsletters, internal corporate portals, and e-mails to give company and team updates, instead of having calls.
• Encourage asynchronous knowledge transfers. Instead of having meetings for knowledge transfers, leverage internal wikis, documentation sites, and portals.
• Consider implementing office hours. Most teams have people who are known for being the go-to person on some topic, which means they are often interrupted. Consider implementing "office hours"—clearly defined times when coworkers can ask the specialists for help.

A final important tip: While mathematically, 2 hours equals 4 blocks of 30 minutes, it doesn't feel the same psychologically. When scheduling important meetings, avoid breaking developers' time into chunks that are too small to allow for concentration.

For instance, if work hours end at 5:00 PM, scheduling a 30-minute meeting at 4:00 PM disrupts focus, as the remaining 30-minute slot isn't enough for devs to regain concentration.

2. Encourage Workflows That Minimize Idle Time

A developer named David submits a pull request and asks a coworker, Priya, to review it. But the PR is massive, and it takes a long time for Priya to review it. While waiting, David has nothing to do. How to solve that situation:

• Encourage small PRs. Leverage short-lived branches and feature flags to create workflows in which developers submit very small PRs that can be reviewed faster.
• Design workflows that use parallelizable items of work. That way, developers can get—or be assigned—another task while they wait for code review.
• Consider pair programming. We'll talk more about this later, but the reasoning here is simple: Think of pair programming as shifting code review left, and doing it synchronously.

3. Don't Cheap Out on Tools

As we've said earlier, subpar tools are an important factor that can harm developers' performance. The tip here is simple. Within reason, give developers the best tools you can:

• If you provide laptops for employees, pick machines with robust specs and settings, necessary for running programming tools smoothly.
• Invest in your CI/CD servers to reduce build and test times.
• Buy developers the licenses for IDEs, databases, and whatever tools they need to do their job properly.
• Invest in tools that reduce idle time—for instance, Devzero helps developers become more efficient by providing always-ready production-like environments freeing developers to focus on coding.

4. Don't Cheap Out on Learning Resources

A common factor that can harm a developer's ability to perform their job well is a lack of necessary skills. Sometimes this is due to a mismatch between the developer and the project. But, perhaps most commonly, this is a circumstantial lack of skills that could be remedied through books, courses, workshops, or other learning resources.

So, the tip here is super simple: Invest in learning resources for your developers, so they can quickly upskill to face the challenges at hand.

5. Increase Your Team's Bus Factor

Have you ever heard of the "bus factor?" Here is how Wikipedia defines it:

The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus". It is also known as the bus problem, truck factor, or bus/truck number.

In other words: If you have a single person who retains vital knowledge, and this person leaves the team and then the project can't continue, you have a bus factor of 1. So, for the future stability of your project, your bus factor should be as high as possible. Ideally, your bus factor should match the number of team members, which would mean that all essential knowledge is equally shared among all members.

How can you increase your team's bus factor?

• Make internal documentation a first-class citizen of your project. Dedicate time during sprints to the creation and maintenance of wiki pages, internal portals, and the like.
• Have an onboarding process for new members and keep it up to date. It's no use having outdated onboarding that fails to provide key project information to the new team member.
• Consider pairing. Not only pair programming, but also leveraging pairing during other activities, such as testing, the writing of technical documentation, prototyping, and more. These activities are priceless opportunities for knowledge spreading.
• Cross-train your team. When team members obtain some critical new knowledge, organize sessions where they can share it with other members.

6. Automate Commonly Done Tasks or Workflows

Automating routine tasks saves time and ensures accuracy in software development.

For instance, integrating Jira or Azure DevOps with GitHub or GitLab so cards on your kanban board are moved automatically—when someone merges a PR, for instance.

Using tools like Doxygen, Sandcastle, or Javadoc, code documentation can be generated from class comments. Similarly, Swagger automates RESTful API documentation. If developers need to request read-only access to a database, for instance, replace that with an automated workflow in which the developer requests the user and their request goes to a queue and is then serviced on a first come, first served basis.

7. Automate or Have Templates for Project Creation

Developers love working on new projects. But greenfield projects do come with their share of routine, boring tasks:

• Creating and configuring a Git repository
• Designing and creating the folder structure
• Creating all the necessary configuration files (e.g., .gitignore, Dockerfile, etc.)
• Creating a CI/CD pipeline
• Setting up automated testing and ensuring it works properly
• Setting up instrumentation

It's possible to streamline some or all of that work with the help of project templates.

The process can vary. Some teams create a custom CLI, while others develop an internal developer portal. Finally, some teams set up several repositories that developers can clone and use as the basis for their projects.

Besides the time that can saved with this approach, another great benefit is the standardization, which helps ensure projects are created following the accepted guidelines for the organization.

8. Consider Pair Programming

Some studies suggest that a pair coding together takes roughly twice the amount of time that it would take a solo developer. But this time is usually compensated for by the higher quality of the pair's output, which results in less time spent debugging and fixing issues.

However, my angle here is slightly different. I argue that pair programming is great for productivity because pairing is a great way to share knowledge and tips between team members. By pairing, a developer can learn:

• Keyboard shortcuts for their IDE and operating system
• Valuable command-line commands and tricks
• Miscellaneous tools that can help during work (e.g., clipboard history managers, screenshot tools, and so on)
• Lesser-known features of operating systems
• Different approaches to debugging

There's a lot that you can learn—or teach—while pairing, and that knowledge will make you more productive even when working solo.

Improve Developer Experience and Productivity Will Follow

Astute readers will have noticed a common thread between most of the tips from this post: They increase developer experience and happiness. Happier, more satisfied developers work better and produce more. It isn't rocket science.

Sure, don't dismiss calculating and improving developer productivity with metrics and tools.

But at the end of the day, developers are humans and perform better when treated as such. With that in mind, I leave you with a final tip: Ensure work-life balance. Burned-out developers are seldom productive. Make sure that overtime is kept to a minimum and, if you're leadership, lead by example by taking care of yourself, taking vacations, and so on.

Thanks for reading!

‍

This post was written by Carlos Schults. Carlos is a skilled software engineer and an accomplished technical writer for various clients. His passion is to get to the bottom (the original source) of things, and captivate readers with approachable and informative technical content.

‍