Hello, World! What Happened to the Inner Dev Loop?
Developers know what makes them happy: working on interesting problems with high-quality tools, few disruptions and collaborating with their peers. Industry innovation depends on keeping these promises to developers so that they’re content and productive.
It might be easy to articulate what makes developers happy, but evidence shows it’s not as easy to achieve. In spite of huge investments in project management and API design processes, developers are less satisfied and productive now than they were 10+ years ago.
So why have these well-intentioned efforts backfired?
The simple answer is that developers spend less time doing what they’re best at — writing and iterating on code, also known as the “inner dev loop” — and more time on everything else. But the issue is about more than productivity losses. To explain why, I’m going to get into some motivational psychology.
Let’s start with a hypothesis: Developers enjoy writing code, and it would serve everyone better to capitalize on that fact.
Why Do Developers Love Coding?
Do you remember your first “Hello, World”? For many developers, the phrase conjures up a feeling of excitement and pride. Learning to code is full of those experiences — the little kick of dopamine you get when you finally debug a tricky function, call a new API or see real data in your UI for the first time. For many devs, the only thing better than having an “aha” moment is sharing the experience with other developers.
As evidence of how much devs enjoy writing code, Stack Overflow’s 2024 Developer Survey showed that over two-thirds of developers code outside of work as a hobby. Developer communities are thriving online and in person. Being a developer is often a core part of their identity. Sounds like things are good, right?
Why Are Devs Unhappy at Work?
The same Stack Overflow survey provides a reality check: Over 80% of developers are not happy in their current jobs. Devs might love coding, but it’s not translating into satisfaction at work.
That stat might not come as a surprise. News stories about quiet quitting, burnout and ghost engineers have been hard to miss in recent years. Even if they don’t provide the complete picture, these trends point to trouble under the surface.
Somehow, as an industry, we’re taking people who love their work so much they do it for fun, and we’re making them miserable. If we’re going to fix this problem, we need to know what we’ve been doing wrong.
What’s Getting Developers Down?
The Stack Overflow survey showed some predictable complaints. Top dev frustrations include overly complex tech stacks for build and deployment, cumbersome systems for tracking contributions, unreliable tools — and too many of them. The biggest frustration by far was technical debt.
The survey also shows the daily cost of disruption and friction. Interruptions are incredibly frequent, and each multiplies its effects by forcing devs to shift context, which increases their cognitive load.
It feels terrible to constantly struggle to focus, especially when all that technical debt is staring you down, and you can’t find the time to do anything about it.
What Motivates Developers?
Frustrated developers are common enough to become the subject of psychology studies, including one published in Empirical Software Engineering (ESW) in 2023. The study backed up many typical developer complaints: They faced too much time pressure, had to deal with multiple conflicting priorities and had their work disrupted too often, either by meetings or endless bug-fixing.
The point of the study wasn’t just to make a list of complaints. The authors wanted to understand how developers could be more motivated and happier at work. They suggest we look to self-determination theory to improve on the status quo.
Self-determination theory suggests that three factors contribute to people’s sense of motivation and well-being at work: autonomy, competence and relatedness. People want to be free to do work they feel good about and to do it in a community that cares about them and their work.
I’d put it more simply: Developers want to feel trusted and valued, and when they do, they’re likely to be happier and more productive.
When Stack Overflow asked developers what they liked about their jobs, the top factors — like improving code quality, learning new tech and driving team strategy — showed just how much people care about autonomy and competence.
The ESW study confirmed that devs who collaborated on their own schedules were also happier and more fulfilled.
The Inner Dev Loop: The Root Problem and the Solution
Another way to put it: Developers need more time in the inner dev loop. If we can deliver on that, we’ll see happier developers, better productivity and quality code.
What Is the Inner Dev Loop?
Developers often talk about being “in the zone” or in a flow state while coding. This is when devs spend a long, uninterrupted block of time iterating continuously through a series of ideas.
That’s the inner dev loop, and it has just a few steps:
- Code: Get an idea written in code form.
- Build and reload: Add that code to the program.
- Inspect the results: See how it works.
- Commit: Save your code.
- Repeat: Revise your idea and keep going.
For a developer working locally on a small code change, the cycle takes four to five minutes. If everything works as expected, the developer moves to the next function. If not, they continue working on the problem while it’s still fresh in their mind.
If a developer manages six hours a day working this way, you’d expect them to make about 70 iterations of their code per day. That level of productivity applied in the right places could take care of your technical debt in no time. Obviously, that’s not happening.
How Did We Lose Sight of the Inner Dev Loop?
At one point, the inner dev loop was what most development work looked like, but two trends emerged that meant the golden age didn’t last long.
First, containerization lengthened the inner dev loop: Building and reloading takes so much longer that devs can do only half as much work as they used to. Trips through the inner dev loop dropped from 70 to more like 35 per day — and that’s assuming a smooth container build process.
Containerization offers some huge benefits, particularly on the production side of technology delivery, and it’s a little misleading to say it’s fully at fault in terms of stretching the inner dev loop — older processes added their own drag. I’m not at all arguing for eliminating containers, but we can’t accept that this is as good as it gets. We must improve the state of the inner dev loop and remove that container tax.
The second problem is that the outer dev loop, the process that occurs after code is written and committed to a version control system, makes it almost impossible for developers to find a “flow state” during the workday. Think about all the non-coding work that makes up the software development life cycle: planning meetings, task assignments, code reviews, status updates, CI/CD management, performance monitoring, incident response, project retros and more, all on repeat. These tasks all serve a purpose but come at the cost of time spent in the inner loop. Obviously, we can’t eliminate them, but the status quo isn’t working.
You can’t build an API without developers writing code. Paul Graham, one of the founders of Y Combinator, warned about the need to protect the “maker’s schedule” back in 2009. He proposed that developers’ needs should shape the schedule for all non-code activities. But between the container tax on the inner dev loop and the massive disruptions to the outer dev loop, the maker’s schedule is more threatened than ever.
How a Weak Inner Dev Loop Frustrates Developers
This is a good time to remind you that your developers are people. Like all people, they’re happier when they feel a sense of purpose and motivation — and when they’re happier, they’ll stick around longer and do better work. Yes, we’re concerned about productivity, but the conversation about the inner dev loop needs to be broader than metrics and money.
Going back to self-determination theory helps explain what I mean. All the taxes on the inner dev loop are hurting the three key components of motivation:
- Developers have little autonomy over their schedules and work processes: With all the additional demands from the outer dev loop, developers don’t have control over when they get to work on code. Tool and process creep make their work unnecessarily complicated and force everyone to work the same way.
- Developers feel less competent when they can’t focus: The demands of containerization and the outer dev loop lead to too much context switching and a greater cognitive load, so devs have fewer mental resources left to do complex, expert work. They’re still competent — they just don’t feel like it because they don’t get the chance to exercise their skills fully.
- Developers don’t feel connected to a process-heavy organization: People need real relationships based on mutual trust and respect, but devs feel like their time is wasted and their knowledge is undervalued. Relationships come through shared experiences and collaboration, not meetings and documentation processes.
Innovation depends on developers who feel invested in their work and motivated to help others grow. Every time we add more time to the inner dev loop or another step to the outer dev loop, we lose the engagement of the people we need to turn future ideas into working code.
Devs Need More Time in the Inner Dev Loop
I started this post by asking why process improvements have backfired. The story of what happened to the inner dev loop gives us a pretty good answer and an obvious course of action.
First, we need to lessen the container tax and shorten the build stage of the inner dev loop. Then, we must reduce distractions and interruptions from the outer dev loop.
There’s no one-size-fits-all prescription for how to proceed: Building a strong engineering culture looks different for every company. But there are some guidelines that everyone can apply:
- Find out your developers’ biggest time-wasters and disruptions: What tools and processes are causing the most interference with their inner dev loop? Ask them, but also measure objectively if you can.
- Consolidate outer dev loop disruptions into specific time blocks: Prioritize the maker’s schedule so developers get uninterrupted focus time.
- Look for ways to streamline developers’ work: The outer dev loop includes tools and processes often built for designers, project managers and DevOps teams. Ensure your API developers can access tools built for their needs, like rapid, shareable mock servers and tools to automate CI/CD pipeline governance.
- Choose tools that reduce the container tax on the inner dev loop: One of the best ways to do this is with ephemeral dev environments, which let developers simulate the production environment on a hosted server with very low latency.
- Don’t be afraid of AI: Your devs aren’t, and excellent tools are available (beyond generic chatbots). AI-assisted spec and code generation can reduce rote work and cognitive load and let developers work on high-value, high-skilled tasks sooner.
Making the right changes allows developers to spend more time on the work they enjoy most, reduces friction and makes them feel more valued.
Developers are highly skilled, passionate people who really like writing code. Prioritize the inner dev loop by choosing developer-focused tools; they’ll repay your trust with more and better code output. And everyone will be happier for it.
