We're all running other people's code
When we think of a day in the life of a software engineer, we typically think of writing brand new code in a text editor—building a new feature, fixing bugs, etc. But in 2022, the vast majority of software engineers are running other people's code. They're building on top of open source libraries, or reusing code from other parts of their company's codebase or from online tutorials.
Investing in and using open source
To say that open source is popular isn't surprising, but the degree to which open source code is essential to modern codebases is. Almost 90% of the engineers we surveyed view open source code as at least somewhat essential to their day to day. Fewer than 1% said confidently that it's not essential.
How essential is open-source code
Investing in and using open source
Obviously, if you built your app on Node, you're technically using open source code all the time, but the dependency goes deeper than that. More than 80% of developers are actively pulling open source code into their work (via StackOverflow or otherwise) at least once per month, and almost 50% are doing it at least once per week. Those percentages are slightly higher for junior engineers vs. senior ones.
Frequency with which engineers pull open-source code into codebase
Senior and managing engineers
Individual contributors
Engineers actively pulling OSS code into their work
>80%
at least once per month
>50%
at least once per week
Investing in and using open source
The increased reliance on open source software certainly catalyzes development, but it also introduces drawbacks and concerns. Between supply chain security (see this CNCF whitepaper; remember the Log4J vulnerability?) and open questions around compensation, power law contributions, and whose responsibility this stuff actually is, norms around open source have yet to fully catch up to the importance of its role in the software ecosystem today.
The StackOverflow memes are true
These numbers are directional, but the story is clear: developers are copying a lot of code. This isn't all from the internet, of course—it also includes copying internal snippets and reusing code you've already written yourself.
Junior developers are copying more code than senior ones, which aligns with the split around using open source code.
Lines of committed code copied and pasted from other sources throughout the week
Senior and managing engineers
Individual contributors
Wrangling machines is hard
It's no secret that deploying apps has paradoxically gotten more complicated despite the proliferation of tools like Vercel, Netlify, etc. Software is a much larger part of the world than it used to be, and that comes with expectations around uptime and reliability that may not have existed in the past.
Accordingly, we're testing our software a lot more these days. It's now standard practice to have integration tests that take hours to run and are difficult to construct—requiring fake data, mocks, and stubs. We're swimming in different operating systems, dark and light mode, browsers, even different kinds of Mac chips.
Unsurprisingly, software engineers would really prefer to spend less time on testing changes, and this goes for individual contributors and managers alike.
Top things engineers wish they could spend less time on
Waiting on machines
As these build processes get more complex—especially with more tests (which is a good thing!)—software engineers are spending more of their time waiting on machines. SQL queries take a long time to run over large tables, database syncs are slow, and a monolith repo can take 20 minutes to build: all of this cuts into precious time.
Regular significant issues in everyday work
Senior and managing engineers
Individual contributors
Wrangling people is even harder
If life was just writing code, things would be simpler; software engineers in our survey reported that human-driven obstacles, like disruptive shifts in project direction, code review latency, or trying to figure out who owns which piece of code, were some of the biggest frustrations they faced day to day.
38%
of engineers say that waiting on people (e.g., waiting for code review, requirements) is a significant issue in everyday work
Wrangling people is even harder
In particular, it takes nearly an entire week for code to make it from a software engineer's brain into production, a stat that may be correlated with how well your company does.
Amount of time for code to fully ship to customer
Senior and managing engineers
Individual contributors
Please give me feedback
“Hey, just wanted to bump this for review—would love to get this deployed by the end of the day.”—57% of developers say it takes more than 4 hours to get a pull request through code review, and 26% say it takes more than a day.
Amount of time for ICs to get a single pull request code review
Whose code is it anyway
More than 30% of developers say figuring out who exactly owns a piece of code—and the associated need to acquire context—can take more than half a work day. Delays in figuring out code ownership are predictably more common at larger companies: 21% of developers at firms with >1K employees say it usually takes more than a work day to figure out who owns a piece of code, compared <10% for companies with smaller employee bases.
Amount of time to figure out who owns a piece of code
Senior and managing engineers
Individual contributors
Sorry for being late, I was in an interview
Everyone is hiring software engineers all the time. And a lot of that hiring burden gets placed on the currently employed engineers: for interviewing, networking, or otherwise. >30% of developers say they'd prefer to spend less time recruiting and interviewing.
The same pattern we've seen for large companies holds true here: almost half (45%) of developers at companies with >1K employees want to spend less time on recruiting. That's 50% higher than developers at companies with fewer than 250 employees.
It's possible this discrepancy is purely due to company size—larger organizations can have longer, more arduous interview processes—but outside of absolute size, growth rate may be playing an important role here. Fast growing companies need to hire engineers quickly, and don't have that many on staff to cover the increasing interview and recruiting burden.
>30%
of developers say they'd prefer to spend less time recruiting and interviewing
Remote work/life
Over the course of the pandemic, some of the most reliable things to see on the front page of Hacker News have been discussions about remote work, for better or worse. Remote work has provided software engineers with the opportunity to try different modalities of work; some like it, and some really don't. To start, developers generally consider themselves about as productive as they were before the pandemic.
Work productivity compared to before COVID-19
Senior and managing engineers
Individual contributors
There are snacks in the office
That being said, a lot of developers find themselves more productive at the office, at least partially. There seems to be a lot of self-selecting going on here. Software engineers working at companies with fully in-office policies (i.e., no remote allowed) were twice as likely to say they feel more productive in person (68%) than software engineers at companies without a fully in-office policy (34%).
Most productive work model
Senior and managing engineers
Individual contributors
I have my headphones on for a reason
We are all after that sweet, sweet flow state, but nothing that's worthwhile is ever easy. Our survey found that on average, engineers have only about 10 hours a week of “deep work” time. Part of this is no doubt due to all of the distractions we outlined above: interviewing, waiting on code review, tests, and builds, and even figuring out who owns what code. Junior engineers have a lot more of this time on average—in fact, 20% more than senior engineers—likely because they've got less administrative overhead to deal with.
Time spent on protected, focused, flow time
What do you think?
They say the only constant is change, and this is definitely true in the world of software; the way that we build, deploy, and monitor our apps is never the same year to year, and neither is how we spend our hours, days, and weeks. We hope this survey has brought a bit of interesting data to the table. Questions? Thoughts? Comments? Tweet at us to get the discussion started (there is an engineer behind the Retool Twitter account).
Meanwhile, give us your take on hot tech topics in the Retool app below.
Survey methodology
Retool and Wakefield, a professional research firm, surveyed 600 software engineers at US companies, between January 5th and January 21st, 2022. Respondents were sourced from a professional online panel; 300 respondents are senior- or manager-level software engineers, and 300 non-senior, non-managing software engineers, or individual contributors (ICs).