This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development
This is not a book about productivity hacks. Alex Soojung-Kim Pang’s Rest: Why You Get More Work Done When You Work Less is a defence of something most software teams treat as a failure state. It draws on neuroscience, the working habits of history’s most productive thinkers, and labour research to make a case that is, once you sit with it, fairly difficult to argue against: rest is not the enemy of good work. It is a condition of it.
I picked this up expecting it to confirm something I already half-believed. What I didn’t expect was how cleanly it mapped onto problems I see repeatedly in software teams: the performative busyness that passes for productivity, the developer who grinds through a problem for six hours and misses the solution that would have been obvious after a walk, the leader who conflates hours in seats with output. Pang has evidence for all of it, and his framing is more useful than most of the leadership books I’ve read on the subject.
The book is written for a general audience, not a technical one. That is, again, part of the point.
Crests and Troughs
Work and rest aren’t opposites like black and white or good and evil; they’re more like different points on life’s wave. You can’t have a crest without a trough. You can’t have the highs without the lows. Neither can exist without the other.
The framing matters because the alternative is to treat rest as subtraction: time not spent working, output not produced. Under that model, rest is a cost to be minimised and the ideal working day is one with as few interruptions as possible. That model produces developers who stay late, skip lunch, and answer Slack messages at 10pm, and it produces teams that are steadily less capable of the sustained, creative thinking that software development actually requires.
Pang’s wave analogy reframes this entirely. The trough is not a failure of the crest; it is what makes the crest possible. You cannot sustain a crest indefinitely. Anyone who has tried knows that the attempt produces diminishing returns and eventually something that looks like output but isn’t: code that passes review but introduces subtle bugs, estimates made without proper thought, decisions deferred because no one has the cognitive resources to make them well.
The wave model is also a better description of how creative and intellectual work actually behaves. Software development does not produce output at a steady rate. It has peaks of high focus and periods of consolidation, connection-making, and recovery. Designing a working environment as though it operates like a factory line, where more hours in equals more product out, misunderstands the nature of the work.
Performing Busyness
It is possible, especially in today’s open office, to see who looks busy, who looks engaged, and who seems passionate about their work. As a result, service workers and professionals are rewarded not just for performing work but also for ‘performing’ busyness at work.
This is one of the more uncomfortable passages in the book, because it describes something that is genuinely common in software teams and rarely named directly. The open-plan office, the always-on Slack culture — all of it creates conditions in which appearing busy is rewarded, often as a proxy for the actual quality of work, which is much harder to observe and measure.
The problem is not that developers are cynically gaming the system. Most are not. The problem is that when an environment rewards visible effort, people respond to that reward signal, often without being aware of it. Time that might otherwise be spent thinking carefully about a problem gets filled with activity. Shallow work crowds out deep work, not through any deliberate choice but because the environment makes shallow work more visible and therefore more legible as productivity.
The modern office was conceptualized as a machine for rationalizing and organizing intellectual labor, and it copied the working hours of factories. But the model has been an imperfect one in creative industries, as it’s extremely hard to measure productivity and quality in creative and knowledge work.
Software development inherited its working culture from an era in which office work was primarily clerical: processing forms, filing correspondence, typing up dictated letters. The eight-hour office day made reasonable sense for that kind of work, where output was largely proportional to time spent and the main variable was effort. It makes considerably less sense for work where the primary output is thought, and where the most valuable thinking often happens in the spaces between focused effort.
I have written previously about what DORA metrics actually measure and why measuring the wrong things produces perverse incentives. Rewarding visible busyness is the most common version of this mistake. If your team is producing velocity points but shipping fragile code, always available but rarely doing their best work, it is worth asking what the environment is actually optimising for.
The Business Case for Rest
Workers who have the chance to get away mentally, switch off, and devote their energies elsewhere, are more productive, have better attitudes, get along better with their colleagues, and are better able to deal with challenges at work. They’re also better able to focus intensely on work tasks.
The case for protecting developers’ rest time is not a wellness position or a soft-skills aspiration. It is a performance argument backed by research. Developers who switch off properly are more productive, more collaborative, and more resilient under pressure. The cost of not resting is paid in reduced output quality, increased error rates, and, eventually, in attrition.
The challenge for leaders is that the benefits of rest are often invisible and the costs of overwork are deferred. A team grinding through a deadline produces measurable short-term output. The technical debt and bugs appear later. The team members who quietly begin looking elsewhere appear later still. Rest’s returns come with a delay that makes them easy to discount.
What Pang’s research makes clear is that the calculus is not actually close. Teams that rest well outperform teams that don’t, across multiple dimensions, over any sustained period. The leaders I have seen build the most effective engineering teams are not the ones who extract the most hours; they are the ones who protect the conditions that allow focused, high quality work, including the condition of adequate rest. If you are serious about engineering leadership development, this is not a peripheral concern.
Your Brain Is Still Working
Sleep scientists can see all this activity during REM sleep, when your brain is spiky with electrical activity. Your brain is just as active when you’re awake but zoning out. During those moments when your mind is wandering and it feels like your mind has gone blank, your brain is actually driving at full speed. It’s just not bothering to take your conscious self along.
Every developer has had the experience of solving a problem in the shower, or on a walk, or in the first few minutes of waking up, after spending hours the previous day staring at the same code without progress. This is not coincidence or luck. It is what the neuroscience of rest describes: the subconscious mind continues processing problems after the conscious effort stops. Stepping away is not abandoning the problem. It is often the most efficient way to make progress on it.
Grinding through a difficult problem for an extended period without a break is frequently less effective than working at it deliberately for a shorter period, stepping away, and returning. The break is not wasted time; it is when the associative, pattern-matching processes that produce insight are most active. This is also, incidentally, why the developer who takes a proper lunch away from their desk often comes back and fixes in twenty minutes what they had been stuck on all morning.
For leaders, the implication is different but equally important. An environment that makes it difficult or uncomfortable to take breaks, step away from the desk, or genuinely disconnect in the evenings is not just a wellness problem. It is actively impeding the cognitive processes that produce the best work. When I worked on engineering leadership development with one client, one of the first things we changed was the implicit expectation around availability outside core hours. The improvement in output quality was measurable within two sprints.
Either Work All Out or Rest Completely
One should ’either work all out or rest completely,’ Cambridge mathematician John Littlewood advised. Even for people whose minds naturally gravitate to their work, having clear boundaries between periods of work and rest allowed them to get more from each. ‘It is too easy, when tired, to fritter a whole day away with the intention of working but never getting properly down to it,’ Littlewood said.
The half-rested state is the worst of both worlds. You are not recovering, because your mind is still half-engaged with work. And you are not working effectively; you are too tired to think clearly. The result is the phenomenon Littlewood describes: a day that feels like work but produces almost nothing, full of low-stakes tasks and distracted browsing that fills the hours without advancing anything that matters.
This is worth naming because the modern working environment makes the half-rested state extraordinarily easy to inhabit. Notifications continue arriving. Slack is open in a background tab. The laptop is on the kitchen counter during dinner. The boundary between working and not working has become genuinely difficult to locate, and many developers have stopped trying to find it. The result is that they rarely work with full focus and rarely rest completely, and they pay for both deficits continuously.
Establishing clear boundaries between work time and rest time requires deliberate effort, and it requires a culture that supports it. A team in which the unwritten expectation is that developers are available in the evenings will not rest well, regardless of what the official policy says. As I explored in the post on psychological safety in development teams, the actual conditions of a team are set by behaviour, not by documentation.
Even during his country’s most desperate hours, when he felt the fate of the nation and civilization hanging in the balance, Churchill found time for a nap. We would be wise to ask if our days and our work are really more urgent.
The Churchill example is one Pang returns to more than once, and it earns its place. If the argument for skipping rest is urgency, the wartime Prime Minister sets a fairly high bar for what qualifies. Most software deadlines, however genuinely important, do not clear that bar. The developer who skips lunch to push a feature, or the engineering manager who routinely answers messages at midnight, is usually not operating under conditions that justify the trade-off, even when it feels that way in the moment.
This is not an argument against hard work or long hours in genuine emergencies. It is an argument for being honest about what constitutes an emergency. A culture in which everything is urgent produces a team that treats urgency as background noise, which means it cannot distinguish between the deadline that genuinely warrants extra effort and the deadline that is simply the result of poor planning. Protecting rest time is, among other things, a way of preserving the ability to respond effectively when something genuinely important does require it.
Rest Is Not a Gift
Rest is not something that the world gives us. It’s never been a gift. It’s never been something you do when you’ve finished everything else. If you want rest, you have to take it. You have to resist the lure of busyness, make time for rest, take it seriously, and protect it from a world that is intent on stealing it.
The preceding chapters establish why rest matters. This one establishes that it requires effort to protect.
The “when I’ve finished everything else” framing is one I recognise from almost every developer and leader I have spoken to about this. The todo list that empties completely before rest is permitted is a fiction: there is always more to do, always one more thing that could be addressed before closing the laptop. Waiting for the work to be finished before resting is, functionally, a decision never to rest at all.
The implication for developers is direct: rest must be scheduled and protected with the same seriousness as any other commitment. A walk at lunchtime, a hard stop at the end of the working day, a weekend that is genuinely a weekend. These are not indulgences; they are the conditions under which your best work becomes possible. Pang’s point is that no one will create these conditions for you. The world, as he puts it, is intent on stealing rest. You have to actively take it back.
For leaders, the obligation is different and arguably heavier. The conditions of a team are set by the behaviour of its leadership. A manager who sends messages at 11pm, who never takes a proper holiday, who treats working late as a badge of honour, is communicating something about the culture regardless of what they say explicitly. Protecting your own rest is part of protecting your team’s.
The Argument in One Sentence
Pang’s book is not a quick read, and it is better for that. The argument builds carefully from the science of what rest actually does, through historical examples, to a practical case for how to pursue it deliberately.
The summary, though, fits in one sentence he provides early on: rest is not work’s adversary. It is work’s partner.
Software development, in particular, requires the kind of sustained creative and analytical thinking that degrades quickly without adequate rest and recovers reliably when rest is taken seriously. The developers who do their best work over long periods are not the ones who work the most hours. They are the ones who work with focus when they work and rest genuinely when they rest.
If you lead a software team, the practical question is whether your team’s environment makes that possible. Whether the implicit expectations around availability, the culture around working late, and the way you model your own rest create conditions in which people can actually recover. If the honest answer is no, that is worth addressing.
If the conditions your team is working in are getting in the way of their best work, that is a conversation I have regularly with engineering leaders. Let’s talk.