2017 Software Developer Productivity Survey

The idea of productive software development seems straightforward. Software engineers produce software. End of story.

But defining productivity is a more challenging proposition, and a valuable one. The average software developer salary in the United States is just over $100,000 (US News), so it’s question worth exploring.

We figured we could start that exploration by asking developers what they think about productivity.

To those ends, we at GitPrime surveyed 1,000 professional software developers from the United States and Great Britain in February 2017. We conducted the survey online with English-speaking professionals who write code as the primary responsibility in their work day. Our goal was to understand their views and perceptions around developer productivity.

Here’s a link to the full survey findings if you’re interested. Below are some of the most interesting takeaways.

My, what big drains you have

The biggest drains on productivity are not technical. We can’t even fault the colossal time suck of Reddit, Hacker News, or Twitter.

Turns out, the biggest drains on productivity are waiting on other people and low-engagement meetings.

This confirms a pretty general belief among software developers: the core problem in software engineering productivity is that highly empowered engineers experience a pattern of being stymied by other, non-technical coworkers.

Overwhelmingly, 41.1% of respondents cite “waiting for other people to do stuff” as an extreme productivity suck in a typical work day, with “meetings where I mostly remain silent” coming in next with 39.9%.

Mirror, mirror, on the wall

Some of our findings go against conventional wisdom, and conventional wisdom says that a) it’s impossible to measure productivity, and b) even if you could measure it, it wouldn’t matter.

It turns out, the vast majority of developers believe there are good metrics to measure software engineering productivity, and they want to know how they are doing.

This supports the growing consensus among engineering leaders that using metrics in software development is essential part of effectively leading teams, for example using metrics to track engagement.

So even if developers may not fully understand how to measure productivity, they care about it enough to want to look in the mirror. In short, they seem to know intuitively that it matters.

New boss, better than the old boss

Not only do engineers want to see their own productivity data—they think their managers should use that data.

Sixty-one percent of respondents said their opinion of their managers would improve if the managers regularly reviewed productivity data to help the team. A further 23% said their opinion would not change.

Managers rightfully have some sensitivity around interfering with the engineering culture of creativity and effectiveness. Yet these numbers are strong enough that managers may want to take note: reviewing and incorporating productivity data is a worthwhile experiment. If nothing else, it’s a low-risk test to validate how receptive your team is to using data to improve productivity.

You say potato, I say Python

It’s simple enough for software engineers to communicate their work to other software engineers. However, the farther these engineers go from engineering, the more difficulty they have explaining what they are doing.

The survey bears this out—engineers believe that executives and especially non-technical stakeholders (such as people in sales, marketing, or accounting) lack sufficient understanding of what makes software programmers productive.

It can be seriously challenging for engineers to take instruction or management from somebody who they believe has no real understanding of the engineering profession. So it appears that non-technical stakeholders may benefit from investing the time to understand the engineering profession. They’ll gain increased respect from their engineers, which will make their professional interactions that much more productive.

Care enough to code the very best

No productivity survey would be complete without taking stock of the larger view. Productivity is only part of the story, after all; high productivity with low quality is far from helpful. So we asked developers what qualities they look for when evaluating their fellow programmers’ code.

Three hallmarks of great programmers stood above the rest:

• Correctness of their code (13.9% of respondents);
• Maintainability of their code (12.7%); and
• Readability of their code (12.5%)

The surprising takeaway here was the high placement of “maintainability of their code,” which we expected to come in much lower. Maintainability’s high result speaks to the collaborative nature of software engineering. A quality programmer builds code intended to be used by other programmers in the future.

Those are some of the highlights from our 2017 survey. Here are the anonymized responses and a link to the SlideShare with the full findings: