circle header

The 2022 state of

engineering time

What are software engineers actually spending their time on? The question has become more pertinent than ever with recent epic shifts in where and how we work. And with talent shortages at an all time high everybody wants to know how happy engineers are with their jobs.

What do engineers want to do less of, or more of? What are the most frustrating parts of the build process? How many hours really get spent writing code? After surveying 600 software engineers, including both ICs and managers, we have some answers, and they might surprise you.

down arrow

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

Hyperlink Image
Copy URL to clipboard
How essential is open-source code
How essential is open-source code
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

Hyperlink Image
Copy URL to clipboard
Frequency with which engineers pull open-source code into codebase

Senior and managing engineers

Individual contributors


Engineers actively pulling OSS code into their work

Hyperlink Image
Copy URL to clipboard

>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

Hyperlink Image
Copy URL to clipboard
Lines of code copied

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

Hyperlink Image
Copy URL to clipboard
Top things engineers wish they could spend time on
Top things engineers wish they could spend time on
Top things engineers wish they could spend 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

Hyperlink Image
Copy URL to clipboard
Issues that happen every day

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

Hyperlink Image
Copy URL to clipboard
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

Hyperlink Image
Copy URL to clipboard
time for ICs to get single PR

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

Hyperlink Image
Copy URL to clipboard
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

Hyperlink Image
Copy URL to clipboard
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

Hyperlink Image
Copy URL to clipboard
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

Hyperlink Image
Copy URL to clipboard
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).