Why 42% of Developers Are Thinking About Quitting Their Jobs
In the media, you often hear about how heavily businesses cater to their developers – but do they? And is it enough or in the ways that matter?
From what I see, companies need to spend a lot more time worrying about their developer experience (DX). If the work experience is rough, unmotivating, or wearisome, no perks can compensate. Depending on the tooling in question, you can be consigning developers to either nirvana or hell — and lots of developers are feeling the heat these days.
Forty-two percent are thinking about quitting their jobs soon – even this year – according to a DigitalOcean survey. Those who aren’t leaving are taking so many sabbaticals that venture capitalists are writing guides on how to do so.
How you recruit and retain these talented individuals is largely a question of how you sculpt their experience — namely, with modern software delivery tooling.
I was Hired to Do What?
There’s a downside to hiring ingenious people and letting them build whatever they want. Clever developers tend to build tools to make their lives easier, but they also sometimes inadvertently paint themselves into a corner. As Gartner explains, “most orgs create homegrown toolchains and then use them far beyond their original design.”
This homegrown approach is common with Jenkins. Lots of custom scripts not only lead to fragmented toolchains, but complications and a multiplicative maintenance burden when that tooling needs to be scaled, replaced, or updated.
As lots of developers tell me, the danger isn’t just that the person who built that script or process might leave — that person doesn’t even have to leave. They need only move on to other projects, and they’ll soon forget the context. Ping that person one or two months later, and they’ll have to go back and relearn their own work. Or worse, they get a 3am call because they’re the only one who knows about the script that’s breaking a delivery. After a few of those calls, they’re ready to quit. That strain grows as the team and company grow, and stand-alone tool siloes create all sorts of issues like fragility and technical debt.
Eventually, these problems fall on the infrastructure and operations leader.
The net result is a lot of lost time. Nearly two-thirds of developers said they spend up to 20 percent of their time on toolchain integration and maintenance each month. According to Stephen Gregory, Senior Principal SRE at Lessonly:
“Jenkins can do a lot, but the deployment primitives just aren’t there. (You can extend it with plugins, but those take up time.) We ran into a bug where if you use a parallel call in a pipeline, it’d fail to call a previous pipeline, and then it’d just be dead. The call to parallel meant the pipeline wouldn’t resume. You always have to consider things like that. How many hours are you investing in figuring out those issues?”
Ultimately, your developers pay the cost. They’re the ones who suffer most when deployment toolchains are fractious and poorly integrated. They’re the ones left spending weekend hours maintaining brittle customizations.
Nowhere is the issue more acute than in the software development lifecycle. It’s a well-documented fact that developers dislike unnecessary toil, and deployments are the most unnecessary of all. Anyone accustomed to DevOps principles does not look forward to spending one day each week just pushing what they’ve coded into production.
If that’s your environment, perhaps it’s enough to tip them over into entertaining calls from recruiters. (Even in the best of times, only 25 percent are not open to such offers.)
A Simple Way to Leap into an Attractive Experience
A full CI/CD platform can give you a lot of what your developers are looking for. In a space where most companies force their developers to use toolchains of 10+ tools, you can reduce that down to a handful. And where 43 percent of developer orgs don’t use any automation at all, you can jump into continuous integration, which 45 percent of respondents to an Atlassian survey said was the whole point of wanting to do DevOps in the first place. It’ll consolidate lots of tools and eliminate toil. Plus, it will ensure nobody’s running custom Jenkins scripts on a local machine that goes off when they log off.
You’ll want to get to a place where your deployment pipelines are built out of small, composable, and reusable chunks. It will require you to ensure that if you want to transition systems or test a framework, your developers don’t sigh, open their browser, and go to Toptal.
How you recruit and retain these talented individuals is largely a question of how you sculpt their experience. And better CI/CD can help you be one of the best.