solo programmer

developer at work

Since XP introduced Pair Programming, the very thought of it has been upsetting people.

On the one hand are managers who are afraid that they’re spending twice as much to get each job done (which isn’t true, but we’ll have to address that elsewhere).

On the other hand, there are developers who dread the entire experience.

  • “If I had to pair program, I would quit my job.”
  • “Nobody will ever agree to work that way. It’s madness.”
  • “Working in a group is too distracting.”
  • “Other people take the joy out of programming.”

In Pair Programming Illuminated, Williams and Kessler reported that around 80% of the people coming into their study expected to hate pair programming. At the end of the study, around 90% preferred programming in groups over working alone.

That’s weird, right? It sounds like Stockholm Syndrome.

How could such an unpalatable thing manage to turn cynics into fans?

And now people claim that working in even larger groups (ensembles1, once called “mob programming”) is even more helpful and enjoyable than working as pairs. It boggles the imagination!

People tend to reject what they imagine programming together would be like, but what they imagine is not the way group programming works.

Instead, they imagine Surveilled Programming.

What is Programming Under Surveillance?

Hiring Surveillance A rushed, live coding exercise where others judge your technique, typing, problem-solving, coding, and design as you work.
The Senior Critic A person with formal authority visits and tells you what to do and what not to do. You have to do what they say. Disagreement is politically dangerous.
Burdensome Junior You are saddled with an inexperienced programmer who watches you work and constantly asks you naive and shallow questions.
Impromptu Performance Without warning or prep, you are expected to put on a show for an audience of your peers.
The Noisy Bullpen You are trying to concentrate on your work while people around are moving through your space, having conversations, answering phone calls, and talking about their work (which is not your work).
The Cellmate You are forced to play host. In addition to getting your work done, you also have to socialize and "play nice" all day. You aren't allowed to spend any time alone.

Imagine a job where these scenarios were all you had to look forward to!

two people with binoculars watching one programmer

one programmer, two watchers

You are right to dread those situations.

We are against Surveilled Programming.

We like working together because done properly, it isn’t like any of the above scenarios.

Then What Is It?

When I suggested that people mistake group programming for working under surveillance, an incredulous reader exclaimed “How could it possibly be anything else!?”

Lets explore that.

The Typist

One of the first things one needs to understand is that the person seated at the keyboard is not programming for the other people. If they were, that would be a failure mode we call “worker/watchers.”

The person sitting at the keyboard is the only person who is not programming. They are not deciding what to do and how to solve problems.

It’s not like the Hiring Surveillance.

Since the keyboardist is not implementing their own ideas, it is also not the Senior Critic situation.

Also, it can’t be the Impromptu Performance, because the person at the keyboard isn’t performing for the onlookers.

By merely examining the role of the typist, we have eliminated half of the mischaracterizations!

Non-Typing Programmers

Do you see the people who are not typing? They’re the ones doing the programming.

Since everyone is engaged in doing the same work it is not the Noisy Bullpen situation: you are not trying to do your work in a whole room full of people doing other things.

You, as one of the non-typists, are vetting your ideas with people who know different parts of the system, who have different levels of skill, and who have different tricks and tips to write, test, and deploy solutions.

You work together to ensure that your ideas won’t cause trouble down the line in other subsystems or processes.

The fact that you only know maybe 10% or 20% of the company’s systems and maybe 60% of the tech stack is no longer a problem - you move fearlessly because you know that your teammates usually know the parts you don’t.

Everyone is a learner, everyone is a teacher. You are not the Burdensome Junior, nor are you required to tend to the Burdensome Junior alone2.

Someone will speak up when a discussion has gone on too long, if it’s time for a break, if someone forgets to run (or write) a test, whenever the code isn’t up to standard, or when some important detail has been forgotten.

In this way, the team is really a collective intelligence; you can relax and concentrate only on the problem, or only on the design, or only on getting out at 5 pm because there’s more than one brain working in parallel and more than one set of eyes on the work.

When you contribute knowledge to the team, you don’t have to write it up in a document or go person-to-person teaching it; they absorb it on the spot. When someone else has a shortcut, you learn it. It’s a high-speed network3 for sharing ideas, tips, and tricks.

The best ideas of the collective mind are relayed to the person doing the typing.

Temporary Roles

The typist and programmer roles (‘driver’ and ‘navigator’ in ensemble terms) are temporary. Everyone gets to relax and type, everyone gets to be idea generators.

Typically a driver’s time at the keyboard is 5-20 minutes, then a rotation occurs. The larger groups tend to rotate more often. Small groups, especially with remote members, tend to have longer turns at the keyboard.

This dynamic keeps us from dealing with situations like The Senior Critic, The Burdensome Junior, and The Cellmate.

Unchained!

Ensembles and pairs tend to take disciplined breaks every hour or when some piece of work completes. Often they will split up and rejoin through the day.

In addition to disciplined breaks, the team may decide that the right way to address a thorny problem is by taking a walk or dispersing to give everyone 20 minutes of solo thinking or research.

If people can come or go then they are not living in The Cellmate scenario.

Ensemble work gives extra freedom: you can walk away, take some time, and come back. When you return, the work will have progressed without you. Maybe when you return someone else will take a short break.

Do you have timesheets or expense reports to fill out?

Is there some mandatory training on your calendar?

Want to check your email?

Need to attend a meeting?

Go ahead.

When you come back, the work has progressed without you. If you don’t like where it’s going, you have time to offer course corrections. If you don’t like work continuing without you, you can stay longer or come back sooner.

But… I’m Faster Alone

Yes, people often say that when they are working alone, they can “get into the zone” and produce many more lines of code per day.

People alone also make many more mistakes. Just by working in pairs, Professor Williams and her team found up to a 40% reduction in errors. As of this writing, I don’t know how much more accurate programmers are when working in an ensemble, but anecdotally we hear that teams are delivering many times per day with very few (sometimes zero) errors.

In informal surveys, I find that corporate teams with solo assignments spend 60-80% of their time working on defects. That’s a lot of time. Reducing defect rework frees up a lot of programming time for new features.

I find that typing code isn’t the delay in most programming teams. The initial thinking and coding is sometimes as little as 5% of the total time it takes to deploy a new feature. The rest of the time is work waiting in queues or being reworked after a rejection. If you can eliminate some of that delay by working in a team, you might not be working faster but you might deploy your work much sooner and more often.

It may be that considering solutions from a wider perspective doesn’t produce a solution as fast as working alone, but sometimes it might produce in hours what an individual’s trial-and-error plus rejection and rework can produce in days or weeks. It doesn’t have to win that bet very often to come out ahead.

What Is That Like?

Great engineers look to improve continuously. People have told us that they learned more in the first month of ensemble work than in the prior two years. It’s a fast way to level up.

Because your context is communal, instead of internal, you needn’t fear being interrupted.

Work gets completed entirely, rather than passed down the line for reviews and testing by outsiders. With less work-in-progress, you have fewer reasons to be interrupted. This lets your work be faster and more predictable.

If this is, indeed, a way to work with greater joy and fewer errors, with more efficiency and fewer dead-end debugging sessions, and to learn while working, then it is worth a try (at least).

Can you join an established ensemble? If you can, even just as an evening hobby or part of an Industrial Logic Workshop, you can see what the proper experience delivers.

If your team would like to give it a try on their own, we have some help for you:

Also, don’t overlook

As you can probably tell, there has been much written and recorded on this topic. The only thing “secret” may be that it’s actually productive, efficient, and fun!

I Just Don’t Like It

That’s fine. We are certainly not in charge of what you can like or not like.

What you like or don’t like isn’t even in charge of what you do. To be healthy you can eat less salt, less sugar, more vegetables and lean meats. To be strong you can endure exercise. To earn pay, you get up early and spend your day not fishing and not playing video games.

But let’s say you feel a hard “no,” what then?

If you can find other ways to overcome the issues with scatter-gather, learn rapidly on the job, reduce errors by 40% or more, and keep the work faster and more predictable then we’re on board.

Don’t keep it a secret! Please lead us!

On the other hand, if you want to work alone even though it leaves all the problems of solo work in place, then that’s a choice between you and your product community.

This may still turn out as you like!

If your company has no real cost or quality pressure, then there is no meaningful, significant difference between these different ways of working. This is good news for you! When there is no significant difference between multiple choices, it becomes a matter of simple preference. Just do what the team (and their managers) prefer.

Notes

  1. Ensemble is considered a more appropriate (at least less inappropriate) term for group programming. See Lisi’s video for more detail on the rename. Other people use the term “teaming” and refer to solo assignments as “unteaming.” ↩

  2. Working in ensemble is one of the fastest ways to bring new hires into a team; the learning speed is remarkable. ↩

  3. A bus topology, specifically ↩