Developer Joy: A Better Way to Boost Developer Productivity – InfoQ

If you’ve ever solved a bug in the shower or had a breakthrough idea while unloading the dishwasher, you’re not alone. For software developers, productivity doesn’t always look like heads-down typing. In fact, according to developers and thought leaders Trisha Gee and Holly Cummins, the best code often starts with a bit of fun, or at least a little time away from the computer.

In this article, Holly and Trisha explore why joy isn’t a distraction from productivity: it’s the secret ingredient. From debugging brain waves in the middle of a jog to cutting out test flakiness, Trisha and Holly explain how to reclaim developer satisfaction and boost output by embracing curiosity, minimizing friction, and giving ourselves a break.

The Joy-Productivity Connection

There is a lingering myth in enterprise environments that productivity and fun are at odds, that leaders have to choose between having a happy team and achieving business results. This is just not true. High-performing teams are happier because they’re thriving, not because they’re slacking off. In fact, not only are productive developers happy, happy developers are productive.

Play isn’t just fluff; it’s a tool. Whether it’s trying something new in a codebase, hacking together a prototype, or taking a break to let the brain wander, joy helps developers learn faster, solve problems more creatively, and stay engaged.

These benefits are backed up by research that consistently shows that happiness, joy, and satisfaction all lead to better productivity (see the research on developer joy and productivity at the end of the article \(^1\) \(^2\) \(^3\)). And when companies chase productivity without considering joy, the result is often burnout and lower output.

Developers Don’t Just Code (and That’s Okay)

Despite what your calendar might say, coding isn’t the only thing you do as a dev. In fact, it might not even be the thing you do most. Surveys find that developers spend less than half their time writing code. This is backed up by Trisha’s informal polling, which finds that it is less than 30 percent.

Developers also spend time in meetings, being in discussions on Slack, and wading through email. On the technical side, time is spent managing other parts of the software process like performing code reviews, troubleshooting issues, writing, running, and troubleshooting tests, and maintaining code or systems.

Software development is not and never has been only about writing code. Communicating with other parts of the business (via meetings or other media) is key to writing the right software and writing correct software. This isn’t necessarily a bad thing: good communication leads to better results. But time spent managing flaky tests, watching a build spin, or deciphering cryptic code? That’s where things get wasteful.

Friction, Toil, and the Death of Flow

So what kills joy on a dev team? Developers get irritated with overheads. This could be process overheads, such as onerous status reporting, having to put the same information into multiple systems, or low-value meetings. It could also be technical overheads, such as clunky APIs, or slow feedback loops.

Aim to reduce friction and toil, the little frustrations that break momentum and make work feel like a slog. Long build and test times are common culprits. At Gradle, the team is particularly interested in improving the reliability of tests by giving developers the right tools to understand intermittent failures. For example, a dashboard of flaky tests, and a visual history of test and build failures. This matters, because we often underestimate how not fun it is when our tests are flaky. If a test sometimes passes and sometimes fails, but with no discernible pattern, it distracts us from the fun parts of coding and sends us down a rabbit-hole of difficult troubleshooting.

Most developers love developing. Frustration happens when we’re kept from doing the development that we love. Whether it's clunky internal tools, redundant processes, or low-value meetings, the result is the same: more time on un-fun tedium translates to less time coding, less joy, and less actual output. People want to achieve things, so if it’s un-fun, that’s a really good indicator that it’s probably a waste of time. Even small tools that remove friction like the live reload experience in Quarkus make a noticeable impact on flow and happiness.

Automate Away The Un-Fun

Good tools remove friction. Great tools make room for joy. Whether it’s using a build cache or accelerating tests, automation gives devs the breathing room to focus on more meaningful (and fun) tasks. If you find you’re spending time on repetitive tasks and no automation tool exists to handle them, invent one. Camille Fournier says in her book The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change:

"We engineers automate so that we can focus on the fun stuff – and the fun stuff is the work that uses most of your brain".

Using more of your brain is valuable, but so (strangely) is using less of your brain. How does that work? We’ll explain.

Embracing Dead Time

One of the most counterintuitive productivity tips is … Do nothing (... Really? Really). When we’re stuck on a problem, we’ll often bang our head against the code until midnight, without getting anywhere. Then in the morning, suddenly it takes five minutes for the solution to click into place. A good night’s sleep is the best debugging tool, but why? What happens? This is the default mode network at work. The default mode network is a set of connections in your brain that activates when you’re truly idle. This network is responsible for many vital brain functions, including creativity and complex problem-solving.

Instead of filling every spare moment with busywork, take proper breaks. Go for a walk. Knit. Garden. "Dead time" in these examples isn't slacking, it’s deep problem-solving in disguise.

And yes, it is still work. Knowledge workers are still working when they’re at the gym, running, or loading the dishwasher. So don’t guilt-trip yourself for stepping away, and remember to remind your boss of the value of downtime.

AI, and the Art of Better Code

As for AI? It has potential. But tread carefully. In our experience, the code generated by AI often prioritizes volume over quality. When we use AI to generate code, we tend to get a lot of code, and it can be pretty flabby. For example, the code will often have comments which just state the obvious and don’t add anything. The flab can be more subtle, too. Some of the Quarkus libraries, like Hibernate ORM with Panache, have beautifully concise programming models that strip out a lot of boilerplate. AI-generated code will often put all the boilerplate back in.

This bloat isn’t just harmless padding. Reading and understanding all those extra comments and lines of code becomes an active productivity drain for future maintainers.

Think carefully when evaluating the productivity impact of AI. If AI can create 90 percent of what we need, but it takes us longer to get that last 10 percent than if we had done it ourselves, it’s not actually a productivity tool, is it?

AI will still help, but we need to use it more effectively. We need to invest time in setting up the tools to use your organization’s specific best practices and design patterns. Using AI is also an investment in ourselves, because using AI well is a skill. Better AI use means better prompts, better training data and fine tuning, and better human judgment about what "good code" really looks like. The future of work will likely require developers to spend more time reviewing code than writing it. Reading code is a learnable skill, so we suggest investing in being able to do this well (and efficiently!).

When we adopt AI into our workflows, we need to think about what our 'true' goal is. Is the aim to write more code, because somewhere there’s a productivity metric which says more code is better, or is the aim to write better code?

Measuring What Matters

Why do we sometimes find it difficult to know if AI-generated code is helping or hindering us? Measuring developer productivity is HARD. Traditional metrics focus on visible activity, like lines of code or number of commits. They’re easy to game and only sometimes reflect the actual value created. Frameworks like SPACE emphasize a more balanced view, and include Satisfaction, Performance, Collaboration, Efficiency and flow, as well as the traditional Activity metrics.

When measuring developer productivity, we recommend doing threat modelling as the first step. When this metric becomes a target, will it still be useful? What behaviors will we see when (not if!) this metric is gamed?

Next, figure out what problem we’re really trying to solve. Is the goal of this measurement to identify low performers and weed them out? Is it to try and create incentives for everyone to work harder? (If it’s either of these, refer back to the threat modeling discussion.) Are we doing the measurement just because we feel we have to have numbers, in order to look like we’re in control?

If the goal is just to have numbers, which won’t really be used for decision-making, perhaps choose a low-cost metric! Or maybe the goal is to identify sources of friction and eliminate them. This is a great goal, but producing metrics of developer productivity may not be the best way to achieve it.

In other words: don’t just measure for the sake of measuring. Know what problem you’re solving and make sure your metrics don’t create new ones.

Final Advice: Fix the Friction, Play More, Work Smarter

Want to be a happier, more productive developer? Get intentional.

Start by tracking what you’re really spending time on, not just the things that are easy to measure, or feel productive. Identify the friction points and look for better tools or processes. Continuous improvement isn’t something you need permission for. Find the papercuts and the friction and fix them. It’s easy to get sucked into living with bad tools, and tedious processes, but these problems can be fixed! There are good tools out there. There are lean techniques for software development. They’re better and they feel better.

And finally, make time for creative play, not just task completion. It’s easier said than done, but try not to cram your day full of ‘productive’ things, just because you think you’re supposed to. Do you have dead time between meetings? Use that time for creative play and you’ll be amazed how much you can achieve.

Research on developer joy and productivity:

1. Bellet, Clement and De Neve, Jan-Emmanuel and Ward, George, Does Employee Happiness have an Impact on Productivity? (October 14, 2019). Saïd Business School WP 2019-13
2. Oswald, Andrew J., Proto, Eugenio and Sgroi, Daniel (2015) Happiness and productivity. Journal of Labor Economics, 33 (4). pp. 789-822. doi:10.1086/681096
3. Shawn Achor, Positive Intelligence, Jan-Feb 2012