What 90,000 developers have to tell us

Follow a network of words that developers use to describe the music they listen to while working and you’ll find some interesting connections. taylor -> swift and imagine -> dragons are obvious, but wandering among other nodes is more interesting. I’d give instrumental -> electronic -> mood -> metal a listen, though there’s always good old prefer -> silence -> none. Sadly, cranking lofi -> radio -> beats in the office isn’t a surefire way to get code cranked out quickly. Based on what nearly 90,000 developers have said, improving developer productivity has more to do with building the right culture, instituting the right processes, and only a little bit of choosing certain technologies.

Source: Stack Overflow Developer Survey Results 2019

Developers are important. This is well known by now, but at the risk of pulling a Steve Ballmer, it’s worth saying a few more times. More than ever, businesses are defined (or redefined) by their skill with software and data. Even industries in which the core focus isn’t technology – from manufacturing to retail, healthcare to media – find that they now need proficiency in software. Who delivers this proficiency in the new software-defined economy? Developers.

Of course, the term “developer” covers a large and heterogeneous set of people from backend to frontend, enterprise employees to solo devs, and those who’ve spent 40 years (or more) building software to those who just started learning. “Developer” may only be marginally more useful as a label than “millennial”, but it’s what we’ve got. I’m casting an intentionally wide net. Whatever the picture of developers is at your organization, it’s incumbent on you to think about how to put them in a position to succeed.

What developers are saying

The 2019 Stack Overflow Developer Survey collected information from nearly 90,000 developers around the world. Some results are unsurprising: DevOps remains A Thing (and A Thing that pays well), JavaScript is the most used language, and 70% of respondents say they’re above average. Some answers are more interesting. Regardless of the buzz, nearly half of respondents aren’t using containers at all, and 80% aren’t using blockchain. 15% are actively looking for a new job, but another 58% are open to opportunities.

When it comes to job priorities, the top three factors among all respondents are technologies, culture, and a flexible schedule. Notably, responses vary by gender here. According to the report’s authors, “developers who belong to gender minorities in tech rank the office environment and company culture as their highest concern when assessing a new job, and are more likely to say the diversity of an organization is a top concern for them.” Technology decisions should be made intelligently, of course, but organizations should put at least as much consideration into company culture and diversity.

This point becomes clearer when it comes to challenges that developers face. The top challenges to developer productivity are organizational rather than technological. These include a distracting work environment, meetings, being tasked with non-development work, and not having enough people for the workload. Of course, developers have plenty of opinions about technology, from languages and frameworks to databases and development platforms. Nevertheless, “inadequate access to necessary tools” is much less of a blocker than organizational challenges.

There are many other interesting findings in the survey, and I encourage you to read through it yourself. At the end of the day, though, what can we learn from it? On most topics, respondents have a variety of opinions. Preferred coding music, of course, is all over the map. Technology preferences differ widely. Developers, like any group of people, contain multitudes. There’s no “hack” to make all your developers immediately better. Nevertheless, there are ways to improve developers’ working conditions. Using certain technologies will pattern match for the top priorities of some developers. Fixing the productivity challenges will require more thoughtful organizational changes. If it’s done right, it’s the organizational change that will have the far greater, and longer lasting, impact.

Improving developer productivity

You could formulate dozens of sets of principles for improving developer productivity, and I’m not going to come up with the ultimate set here. One general approach for building a culture of innovation that I like was discussed by Larry Glenn, an engineering leader with experience at companies including JetBlue, Saks Fifth Avenue / Hudson’s Bay Company, and Jet.com, at MongoDB World 2015 Larry’s presentation, on building a culture of innovation at HBC, put forth the principles of Interfaces, People, Time, and Tools, which I’ll modify slightly here:

• Processes and organizational structures should support working efficiently. Developers shouldn’t be fighting fires all the time, handling last-in first-out requests for work from anyone in the business who can email them, or constantly waiting on work that’s blocked elsewhere in the flow. There needs to be a clear methodology for defining, prioritizing, and assigning work, and the organizational structure should reinforce that. There are plenty of detailed frameworks you can pick that are designed to enforce this, but the fundamental goal is to build a set of processes and an organizational structure that are conducive to actually getting work done.
• People are people, not resources. It’s all too easy to lose sight of this when you’re planning work in engineer-months. It’s important to remember, though, that developers are individuals with different skills and desires, who are excited about solving interesting problems. As an extension of this, the more that work can be framed in terms of problem spaces rather than specifics – e.g., “designing efficient messaging systems” vs. “hooking this particular CMS to that one order fulfillment system” – the more latitude developers have to make the right decisions and enjoy their work.
• Time translates to quality. Preserving long blocks of time to focus on a problem is crucial: that means minimizing distractions, reducing time spent in meetings and clustering them whenever possible, and cutting out unenjoyable non-development work. Of course, it’s also crucial to budget enough time for the work at hand. Estimated timelines are rarely accurate, usually overly aggressive, and always a bummer to produce (and revise). Knowing that, try to step back and take a second look at an estimation to ask if it’s really reasonable.
• Tools are never a panacea, but they can definitely improve productivity. When it comes to tools – languages and frameworks, laptops and other hardware, IDEs, whatever – consider what makes sense for the problems you’re solving and what your team wants to use. Where possible, give developers autonomy in choosing tools. Where that’s not possible, as when a decision needs to be made that affects how everyone works, make sure to ask for input. Give developers the opportunity to explore tools and make a case for why they would be the right choice for the situation at hand. The tools available now are better than they ever have been, and simultaneously easier to try out.

None of that is terribly surprising. While software development has all sorts of specific details, improving developer productivity is not that different from improving anyone’s productivity, when you boil it down to general principles. Use processes that are more helpful than they are painful, give employees the scope to do good work, make enough time for the work and use it well, and give workers the tools they need to do the job. Laying the foundation for improving developer productivity has the potential to deliver incredible results, both those that are foreseeable (shipping faster, improving quality) and those that aren’t (coming up with the idea for your Next Big Thing).

At MongoDB, we know this to be true. The company was founded by developers to help other developers, and we’ve seen thousands of customers realize the benefits of improved developer productivity. In this series of articles, we hope to continue bringing the voice of the developer to the fore.

You may have very different opinions about what’s important for developers. I’d love to hear from you. Reach out, or find me in person if you’re coming to MongoDB World.

And hey, you could always try some minimal -> house -> jazz.

Check out Larry Glenn, VP Platform and System Development at HBC Digital, speaking at MongoDB World about building a culture of Innovation at Saks Fifth Avenue.