Against the Myth of the Efficient Individual
Software is not manufactured. It is understood. And understanding is a shared act.
This entry follows on from this Tale from Le Bon Mot:
Smoke and Heresy
Walk into any engineering organisation and you will smell it before you see it. Not coffee. Not ambition. Not even fear. You will smell the faint industrial tang of the nineteenth century.
Dashboards glow like factory foremen’s clipboards. Utilisation charts twitch nervously. Tickets are assigned as though they were rivets. Someone, somewhere, is counting “productivity,” while someone else is trying desperately to look productive.
The mythology is rarely spoken aloud. It does not need to be. It is embedded in tooling, performance reviews, sprint boards, and in the small embarrassed cough that accompanies two engineers sitting at one keyboard.
“Shouldn’t one of you be doing something else?”
This is the inherited catechism of software engineering: that work is output, that output is individual, and that individual output can be measured like bolts produced per hour. It is the religion of the factory floor, recited in stand-ups.
And like all religions, it has its unquestionable saints. The lone genius in the dark hoodie, the 10x engineer, the heroic all-nighter who “just got it done.”
Against this orthodoxy, pair programming and mob programming are heresies. They look inefficient. They look indulgent.
They look like five chefs stirring one pot.
And yet, over time, they produce fewer defects, greater resilience, shared ownership, and teams that do not collapse when one saint ascends, or descends, to another company.
The clash is not procedural. It is mythological. Until we name the myths, we cannot understand why pairing feels uncomfortable in organisations that otherwise profess to value quality, collaboration, and learning.
So let us drag them into the light.
The Factory Myth
Myth: Software development is manufacturing.
Corollary: Efficiency is maximising individual output.
The factory metaphor rewards:
Parallelisation.
High utilisation.
Measurable throughput.
Individual accountability for units produced.
Pair programming violates this visually. Two people at one keyboard appears to halve output. A mob appears to reduce it further.
But software is not assembly. It is not the repeated shaping of identical parts. It is the navigation of uncertainty. Manufacturing optimises for repeatability. Software optimises for correctness under ambiguity.
Pairing reduces:
Defect injection.
Rework.
Architectural drift.
Knowledge silos.
Factories optimise for resource efficiency. Healthy software team habitats optimise for flow efficiency and learning velocity.
When you apply the wrong metaphor, good practices appear wasteful.
The Productivity Metric Myth
Myth: Individual productivity is measurable and comparable.
This belief is encoded in:
Lines of code.
Tickets closed.
Pull requests merged.
Individual velocity charts.
Individual performance incentives.
Pairing scrambles attribution. Mob programming erases it entirely. Who “did” the ticket? Throw AI assistance in the form of a Djinn or three to a mob programming exercise and the same questions emerge.
If your systems reward visible individual motion, collaboration becomes professionally dangerous. The results tend to be:
Defensive ownership.
Reluctance to share work.
Silent competition masquerading as teamwork.
Pairing and mobbing require that value be measured at the team level:
Lead time.
Change failure rate.
Defect density.
Knowledge distribution.
Where measurement systems worship the individual, pairing and mobbing will always feel subversive.
The Lone Genius Myth
Myth: Great software is written by exceptional individuals in isolation.
This myth flatters the ego. It also corrodes systems. It creates:
Code as territory.
Review as judgment.
Knowledge as leverage.
Pairing dissolves authorship. Mob programming annihilates it.
In a pair:
Thought is externalised.
Design is interrogated in real time.
Assumptions surface early.
In a mob:
Architecture is collectively owned.
Learning is continuous.
Ego must shrink for the system to grow.
The lone genius myth is comforting because it assigns greatness to a few. Pairing is uncomfortable because it democratises competence.
The Utilisation Fallacy
Myth: Everyone must be fully busy at all times.
High utilisation looks efficient on spreadsheets. It feels catastrophic in complex systems. High utilisation produces:
Long queues.
Multitasking.
Context switching.
Increased error rates.
Pairing reduces parallelism deliberately. It aligns attention. This looks inefficient locally. It reduces systemic delay globally.
In complex cognitive work, slack is not waste. Slack is resilience and space for learning.
The Misread Garden
In reaction to factory thinking, some adopt ecological metaphors — “rewilding,” “gardening,” “organic systems.”
These metaphors are healthier than factories, but can be misread.
If interpreted as:
Radical autonomy.
Individual creative wandering.
Leave-me-alone craftsmanship.
Then pairing feels like constraint. But real ecosystems are interdependent networks. They are dense with feedback loops. Nothing survives alone.
Properly understood, ecological metaphors strengthen the case for pairing:
Shared context is soil.
Dialogue is pollination.
Collective design is symbiosis.
Here on the Enchiridion we love the Habitat metaphor, but it can also suffer if seen as license for chaos.
The Deep Work Absolutism
Myth: All meaningful work requires solitary focus.
Deep work has its place, but absolutism distorts judgment.
Some work benefits from solitude:
Research.
Writing.
Reflection.
Some work benefits from synchronised cognition:
Architectural decisions.
Risky refactors.
Unfamiliar domains.
AI-assisted code interpretation.
Pairing and mobbing are not anti-focus. They are shared focus.
The AI Amplification Illusion
Myth: AI increases individual throughput enough to make collaboration optional.
AI expands:
Code generation speed.
Idea surface area.
Architectural possibility.
It also expands:
Error velocity.
Confident wrongness.
Complexity injection.
Pairing and mobbing become more important, not less. Two or more humans interpreting AI collaborator output are safer than any one human deferring to it.
Mob programming in an AI age:
Cross-validates suggestions.
Prevents silent dependency on generated patterns.
Maintains shared understanding of system intent.
AI magnifies individual output. It also magnifies individual blind spots. Collaboration is a counterbalance.
Some practices to consider
Optimise for Team Outcomes
Measure lead time, stability, and shared ownership — not individual velocity.
Normalise Rotation
Rotate drivers and pairs deliberately. Reduce hero patterns.
Make Psychological Safety Explicit
No keyboard grabbing. No sarcasm. Curiosity over certainty.
Choose the Mode Intentionally
Pair or mob when uncertainty, risk, or design complexity is high.
Retrospect the Collaboration Itself
Inspect not just the code, but the practice.
Some things to avoid
Treating pairing as permanent rather than situational.
Forcing mobbing on mechanical tasks.
Using collaboration as theatre.
Failing to adjust performance systems to reward team success.
Ignoring energy limits.
A helpful checklist
Are we measuring individuals or systems?
Are we optimising for utilisation or flow?
Do we reward ownership or stewardship?
Are disagreements settled experimentally?
Is knowledge distributed or concentrated?
When we mistake software for a product rolling off an assembly line, we will resist collaboration.
Consider a team face a high-risk refactor. They have three clear ways they could respond depending on if they are bought into the Factory metaphor:
Factory thinking response:
Break into tickets.
Assign individually.
Review later.
Pairing response:
Two engineers navigate the unknowns.
Decisions are surfaced immediately.
Defects drop before they are born.
Mob response:
Whole team explores the architecture.
Shared mental model forms.
Downstream work accelerates.
The difference is not speed of typing. It is speed of shared understanding.
When we recognise software engineering as a living, evolving, cognitive system, we will design our practices accordingly.
Software is not manufactured. It is understood. And understanding is a shared act.
Want to meet IRL? I’ll be speaking at a number of great events in 2026.