Cal Newport writes about knowledge work. Gene Kim writes about DevOps transformations. Dave Farley writes about continuous delivery. Robert C. Martin writes about software craftsmanship. They come from different worlds, use different vocabularies, and address different audiences.
And yet they are all saying the same thing: producing more is not the same as creating value.
The Common Thread
Newport’s Slow Productivity rests on three principles: do fewer things, work at a natural pace, obsess over quality.
Kim’s The Phoenix Project introduces the Three Ways: flow, feedback, and continuous learning. His follow-up The Unicorn Project describes the Five Ideals: locality and simplicity, focus and flow, improvement of daily work, psychological safety, customer focus.
Farley’s Modern Software Engineering argues that software development is an exercise in learning and discovery. He emphasizes iterative work, fast feedback, and empirical approaches over big upfront design.
Martin’s Clean series makes the case for professionalism and quality as non-negotiable foundations. Code should be readable, systems should be maintainable, and developers should take pride in their craft.
Strip away the terminology and the pattern is clear:
- Less is more. Fewer concurrent projects, smaller batches, shorter feedback loops.
- Flow over busyness. Uninterrupted focus beats fragmented multitasking.
- Quality is not a phase. It is built in continuously, not inspected in at the end.
- Trust enables speed. Autonomy and psychological safety are not luxuries, they are prerequisites for good work.
- Learning is the work. Software development is discovery, not manufacturing.
This is not news to anyone who has been paying attention. What is harder to find are concrete examples of what this looks like in practice, especially in regulated industries where process overhead is often seen as inevitable.
When Everything Clicks: A Greenfield Project
I once worked on a greenfield project where I rebuilt a component from scratch in C. It was embedded software in a regulated industry, which usually means heavy process overhead, but this project was different.
We had a strong product manager who spoke directly with customers and kept us developers in close, ongoing exchange. That meant we understood what customers actually needed without waiting for a formal technical specification. This was unusual. In most projects I had been on, requirements arrived as finished documents, weeks after the customer conversation had happened.
The workflow stayed tight throughout. I would refine a piece of the design, write the tests, implement the change, and open a pull request. Communication happened asynchronously over chat. Code reviews came back fast. We could deploy directly onto test hardware and get immediate feedback, not just on our own component but on how it behaved in the full system. Small changes, integrated frequently, validated against reality rather than assumptions.
What made it work was the presence of trust. No one told me which design pattern to use or how to structure my modules. I could start building before having every detail figured out, try things, fail fast, learn, and iterate.
The principles from the books were not something I applied consciously. They just described what was already happening when the conditions were right.
When It Is Hard: Legacy Systems
But here is the question I kept asking myself: does this only work for greenfield projects? What about the legacy systems, the inherited codebases, the regulated environments where everything feels immovable?
I have worked on several of those too. And the answer is: the same principles apply. It just requires a different approach.
The improvements came through deliberate, incremental steps:
- Start with requirements. Reduce them to the essentials. Focus on what and why, not how. Bloated specifications create bloated software and tests. When you force clarity at the requirements level, you often discover that half the complexity was never necessary.
- Improve the documentation. This sounds mundane, but it is powerful. The act of documenting what the system actually does, not what it was supposed to do, gives you a first sense of where the architecture has drifted and where refactoring is possible.
- Write tests against the legacy code. Unit tests, component tests, whatever you can get in. They are your safety net for everything that follows. Without tests, every change is a gamble. With tests, you can move with confidence.
- Modularize through refactoring. And critically: remove unnecessary code entirely. Dead code is not harmless. It is confusion waiting to happen. Every line you delete is a line no one has to understand, maintain, or debug.
- Reduce tool fragmentation. Instead of a separate tool for every step, limit yourself to two or three. Every tool switch is a context switch, and context switches kill flow.
- Keep the team small and the communication direct. Every handoff, from requirements engineer to architect, to developer, to tester, loses information. In my experience, a small group of developers working closely with a strong product manager creates far more value than a large team with many handoff points.
This is Kim’s Third Ideal: improvement of daily work. The Scout Rule, popularized by Martin: leave the code cleaner than you found it. It is Farley’s emphasis on managing complexity through continuous, small improvements. It is not a separate initiative. It is how the work gets done.
The Myth of Regulatory Constraints
There is a common excuse in regulated industries: “We would love to work this way, but compliance makes it impossible.”
I do not buy it.
Standards like ASPICE describe best practices. You need requirements, architecture, design, and tests. You need traceability and verification. But ASPICE does not prescribe how heavyweight those need to be. You can do all of this lean. The standard asks that you demonstrate rigor, not that you drown in documents.
On one project, we replaced huge specification documents with a structured set of few requirements, each linked directly to its test. The auditor accepted it. The team could actually maintain it.
The real barrier is rarely the regulation. It is the assumption that regulation demands bureaucracy. Once teams realize they can improve incrementally, within the rules, the path opens up.
I have seen this happen. Teams that thought they were stuck discovered they had more freedom than they assumed. The constraint was not the standard, it was their interpretation of it.
Kim describes exactly this in The Phoenix Project: the bottleneck is rarely where you think it is. Often the biggest constraint is not technical or regulatory, it is organizational belief.
The Work That Does Not Show Up on the Board
There is a less obvious effect of this kind of work, one that affects the people writing the code as much as the code itself.
There is a concept in psychology called self-efficacy: the belief that your actions matter and that you have agency over how you do your work. Research consistently shows it is one of the strongest predictors of motivation, performance, and resilience in knowledge work.
This is what depth over busyness enables. Not just better software, but better working conditions. The sense of ownership over technical decisions. The tight feedback loop. The freedom to explore and recover on your own terms.
The best developers I have worked with all share one quality: they see work that others overlook.
They notice that a module has grown too complex, that an abstraction no longer fits, that a dependency could be removed. They write the test that will save three hours of debugging next month. They improve the documentation so the next person does not have to reverse-engineer the code. They delete the dead code that everyone else steps around.
This work rarely shows up on a board. There is no ticket for “make tomorrow’s feature possible.” No story points for removing confusion. But it is often the reason the next feature can be built cleanly instead of hacked on top of existing debt.
I think of it as gardening. A garden is never “done.” It grows, it changes, and it needs continuous care. Good developers treat codebases the same way. They do not wait for permission to pull weeds. They do not need a feature request to improve the soil. They understand that small, consistent effort prevents the kind of decay that eventually requires a rewrite.
The job of a software engineer is not to produce code. It is to reduce complexity and create value. Doing fewer things is not laziness, it is judgment. Working at a natural pace is not slowness, it is sustainability. Obsessing over quality is not perfectionism, it is professional responsibility.
Starting Today
The conditions for this kind of work can be cultivated. Not everywhere, not always, but more often than we assume. It starts with one project, one team willing to experiment with fewer meetings, smaller batches, more trust.
Newport, Kim, Farley, and Martin come from different worlds. But they all arrived at the same place: less, but better. The only question left is whether we are willing to do less, so we can build something that matters.