Working with Coders is worth your time today
Summary and (some) reflections on the guide for software development for the non-techie
Working with Coders is a book by Patrick Gleeson written in 2017 for people that work with software developers, about how to work better.
Working with Coders — reflections a decade later
Working with Coders by Patrick Gleeson (2017) primarily aimed at non-engineers to help them understand how to collaborate more effectively with technical teams.
So why revisit this book now?
I’ve spent the last 20+ years working as a developer/engineer and, more recently, as an engineering manager. Over time, one pattern has become clear: the success or failure of software initiatives is not determined by technical complexity alone. More often, it comes down to communication, expectations, and alignment between technical and non-technical stakeholders.
That’s precisely the space this book tries to address.
At first glance, a book written nearly a decade ago might feel outdated in an industry that reinvents itself every few years. But interestingly, many of the core tensions it describes—misaligned expectations, oversimplified analogies, and the gap between “what is asked” and “what is needed”—are still very much present today.
There’s also a personal connection: I used to work with the author’s sister, who transitioned into the profession from a non-computer science background. She consistently demonstrated how effective collaboration doesn’t require deep technical expertise, but rather clarity of thought, curiosity, and respect for the craft. Her recommendation of this book reinforces its intent: bridging the gap between technical and non-technical worlds.
I’m using it as a baseline to help operational and business stakeholders better understand how software is actually built—and why it often behaves in unintuitive ways.
Main takeaways
1. The test of time
Despite being written in 2017, the book holds up well because it focuses on fundamentals rather than trends. Frameworks, tools, and methodologies evolve, but the human dynamics around software development change much more slowly.
Many of the issues described—unclear goals, shifting requirements, and miscommunication—are not artefacts of a specific era; they are structural characteristics of building software.
2. Building a house isn’t writing software
A core argument is that software development is often compared to construction—and that this analogy breaks down quickly.
In construction, you define the blueprint and execute. In software, building the system is often how you discover the real requirements.
This leads to familiar failure modes:
Objectives are unclear or overly optimistic
Requirements are over-specified in the wrong places
Stakeholders only understand what they need after seeing something working
Existing systems and sunk costs constrain decisions
In practice, the issue is rarely lack of knowledge—it’s premature certainty.
Estimates then get converted into commitments, and that’s where things start to unravel.
3. User feedback: when reality corrects intent
Every project hits the same moment: users interact with the system and realise that what they asked for is not what they actually need.
This is not a failure—it’s part of the process.
The challenge is managing expectations:
Software operates in context, not isolation
Unknowns will surface, often late
Early versions should be treated as learning tools
Estimates should support decisions, not act as promises. They help answer:
Is it worth building this now, or investing somewhere else?
4. Fragility vs anti-fragility in development
Software systems—and the processes around them—can be:
Fragile (break under change)
Robust (resist change)
Anti-fragile (improve through change)
Many teams unintentionally operate in fragile setups while aiming for robustness.
There’s also a useful distinction between:
agile as a mindset
Agile as a framework
Some implementations of Agile introduce rigidity rather than flexibility. Scrum, for instance, works well in constrained environments but can become mechanical.
In software, effectiveness matters more than efficiency. Optimising too early assumes we already know the right thing to build.
5. Estimates as negotiation tools, not predictions
Estimates are frequently misunderstood.
They are not:
Deadlines
Commitments
Performance metrics
They are inputs for trade-offs:
Scope vs time
Quality vs cost
Speed vs maintainability
When used properly, estimates enable alignment. When misused, they create tension between teams and stakeholders.
6. The illusion of visibility
From the outside, software looks simpler than it is.
Stakeholders typically see:
A working demo
A clean interface
A successful use case
They don’t see:
Integration complexity
Edge cases
Operational risk
Long-term maintenance
This creates a perception gap.
Bridging that gap is less about explaining technical details and more about translating into impact:
What happens when this fails?
What’s the customer impact?
What are we trading off?
This is especially relevant when influencing decisions without relying purely on authority.
7. Tools shape behaviour more than we admit
A practical observation: tools often define how teams work.
For example:
Using JIRA tends to push teams toward Scrum-like workflows
Alternative approaches become harder to express
The tool subtly enforces structure
This can be useful for consistency, but also limiting.
Over time, teams risk optimising for what the tool makes easy, rather than what the problem requires.
Closing thought
The enduring value of Working with Coders is not in prescribing a methodology, but in highlighting a gap: software development is as much about people, expectations, and communication as it is about code.
A decade later, that gap still exists—and if anything, it’s visible with AI or not. Thanks again Patrick for the great book!