Introduction
For years, I've been searching for ways developers can shield themselves from misguided productivity management. I've tried everything, but management persists. Arbitrary targets and proxy metrics seem endless.
The idea respawns somewhere new as soon as it gets its head chopped off. Just look at how often someone tries to start a new company based entirely on the claim that they've figured out how to reduce programming effort and efficiency to a handful of numbers. ("No! I swear! This time it's for real.")
Most days, it feels like programmers are doomed to live under the outdated ideas of scientific management.
But today, I had an idea—something that's been right there in front of us all along: Pair Programming.
The Hidden Power of Pair Programming
Besides the benefits its proponents tout—faster onboarding, better sharing of institutional knowledge, more natural code reviews, increased team energy—pair programming could be the key to freeing developers from relentless individual scrutiny.
Here's the idea: if developers collectively insisted on pair programming—making it an absolute requirement rather than an occasional practice—they could effectively shield themselves from individual metric tracking.
Because there would be no such thing as individual programming effort.
Bam!
Restructuring Task Management Systems
To achieve this, existing software tracking systems would need adjustments. Most importantly, no developer would ever pull individual tickets from task management systems like Jira, Pivotal Tracker, or Asana. Instead, tickets should always be claimed by pairs or groups. While these tools don't inherently support team-based ticket assignment, creative solutions exist. Teams could adopt shared names or aliases for pairs, ensuring no task is tracked back to a single individual.
This seemingly minor shift is revolutionary. By removing individual accountability from tracking systems, management loses the ability to target developers individually based on arbitrary metrics. The burden is lifted.
Strength in Numbers
The benefits don't end there. When developers work in pairs or small groups, they can more effectively challenge unrealistic expectations or poorly conceived requirements. It's far harder to dismiss the collective voice of two or more developers pointing out problems than to label an individual as lazy or incompetent. Additionally, pair assignments diffuse blame and prevent unjust targeting of any single developer for setbacks or delays.
This realization excites me, although I know it's not entirely new. (I'm sure that if Kent Beck is reading this, he’s saying, "Well, duh!")
Pair Programming as Civil Disobedience
Pair programming can be more than just an effective development practice; it's a subtle yet powerful act of civil disobedience. By insisting on pairing, developers reclaim autonomy and push back against micromanagement without significant confrontation. They merely have to advocate for the already well-established benefits of pairing and insist on using it.
Developers should unite under this simple principle: "I only pair." Make the banners, print the flyers, knock on doors, and gather signatures. It's time to restore sanity, productivity, and enjoyment to programming.
Individuality Still Thrives
By no means does pair programming erase individuality. Like participating in a college study group, pairing augments individual capacity through sharing and collaboration. Developers still have ample opportunities to independently research new ideas, prototype solutions, and deepen their expertise outside tracked tasks. This balance allows developers to express unique strengths and autonomy while collectively resisting harmful management practices.
Individual talents will still shine—just in more collaborative moments, which gives more satisfaction anyway. Pairing doesn't hide anyone's skills; it merely enforces what Tom DeMarco and Timothy Lister suggested in their influential book Peopleware:
Work measurement can be a useful tool for method improvement, motivation, and enhanced job satisfaction, but it is almost never used for these purposes. Measurement schemes tend to become threatening and burdensome.
In order to make the concept deliver on its potential, management has to be perceptive and secure enough to cut itself out of the loop. That means the data on individuals is not passed up to management, and everybody in the organization knows it. Data collected on the individual’s performance has to be used only to benefit that individual. The measurement scheme is an exercise in self-assessment, and only the sanitized averages are made available to the boss.
…The individuals are inclined to do exactly the same things with the data that the manager would do… The manager doesn’t really need the individual data in order to benefit from it.1
Programmer’s can still measure anything the would like about their own performance. They are simply cutting management “out of the loop”.
Addressing the Parallelism Myth
Of course, some will argue that pair programming removes the benefits of parallelism: two people could otherwise be working on two separate tasks, theoretically doubling output. But this doesn't hold in practice. Firstly, two programmers working on the same task usually complete it faster and with fewer errors than an single developer. Secondly, pair programming removes one of software development’s greatest productivity killers: code reviews.
In traditional workflows, code languishes for hours or days awaiting review and approval. With pair programming, peer reviews become intrinsic to the development process. As soon as a task is completed, it has already been sufficiently reviewed and can be immediately merged into the main code branch. In most cases, this speedup alone outweighs any supposed benefits of parallelism.
Conclusion
The path forward is clear: remove individual names from task tracking systems, insist on pairing, and reclaim our profession. Together, we can resist misguided productivity metrics and restore joy, sanity, and true productivity to software development.
Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister
Why would individual effort be a bad thing? Why is this something you’d like to “hide”, for a lack of a better word?
I feel you are on the right track considering pair programming and not allowing individuals to pull tickets.
But at the same time, even these are limited solutions when much more effective approaches are available, such as cross-functional teams who create software, find bugs and solve them together. In that environment, of perhaps 8-14 people, the software creation process is informed by identifying bugs and solving them in a virtuous cycle. In many cases it may not be necessary to record much info if any for small bugs or feature improvements before release.
There are many examples of this approach from team-based continuous improvement practices at companies like Toyota, Buurtzorg or Favi.