andrei

Test

Test

I'm fortunate enough to work in a team that does a lot of pair programming. I feel I'm super productive. Last time I was this productive, I was working in another team where this was a common practice.

Pair programming

Pair programming is basically when two people work together on the same computer. One is a driver and one is a navigator. The driver does the typing and takes care of the details while the navigator sees the big picture. From time to time they switch roles. A lot of pair programming supporters try to explain why pair programming is more productive than going solo. I think a better approach is to list when going solo is less efficient.

Code review generates a lot of waste

In some teams developers work alone by default and once they finish the work, they submit it for review to their team. The team comes up with feedback that gets integrated into the original changes. This might sound natural but it often leads time spent on things that don't matter. Let's say you work for 3 days on something. During review somebody noticed you went off the rails for one day. Gives the feedback. You mumble a bit and then do the fix. The work goes up to 4 days and gets merged. Can you spot the waste here? There was one full day of work that went straight out the window. Multiply this 33% of extra work for how often do you think this happens.

During pair programing this does not happen. The code gets effectively reviewed before it is written. If the two developers agree on a solution, it gets written. If they don't agree, they call in a short design session with one or more other developers and get to a good design. Code review is fine, but it should be used only some times. It should be the exception not the rule.

Working alone with new tech will slow you down

As a developer you often need to deal with really complex issues. Some are outside of your expertise and feel really new to you. What happens then? You move really slooooow. You have no clue how to fix that CSS issue, or that DevOps problem since you might not be the CSS person or DevOps person in the team. You will not be blocked so it does not make sense to ask for help. If you do ask for help, some other dev will fix your immediate CSS problem and then run along to their issues. Your problem is your lack of CSS knowledge, not one concrete issue that you need to pass.

When you pair, you can get the CSS guru to work with you on that task. He or she will not only speed you up, but will also help you understand and maybe even enjoy working with CSS.

You read more code than you write

This is a known fact in software development: we read more than we write. You need to read more to understand where your change needs to fit in. Since you only have a brain and two eyes you will need to stuff your head with a lot of code before you find the perfect spot to add your modification. This will waste a lot of time.

Pairing gives you an extra brain and an extra pair of eyes. The other brain has seen code yours did not. “Oh, I know why this happens: I debugged this issue 2 weeks ago.“. Since your pair understands some part of code and you understand the other part, together you have a bigger picture. The two of you will spend less time.

Your pair will keep your over-engineering in check

A really frequent source of waste that is not talked about is over-engineering. This happens when one developer solves a problem in a really complicated way. It happens to all of us. Over-engineering causes waste in two ways. On one hand you spend more time on a complex solution instead of less time on a simple solution and on the other hand future developers will spend more time understanding/changing/maintaining a complex solution. While your extra effort might not be big, the mine field you can leave behind will slow your entire team months to come, if not more.

Your pair will ask you questions like “Is this the simplest thing that could possibly work?”. You might be on your way to building a 3 day solution when a 1 day solution might suffice. A simple question can save you 2 days of work. It will maximize the amount of work not done. This question will make you see the error of your ways, and will also save you time. At some point in the future you might return the favor to your pair.

8 hours of work? yeah, right!

Some people like to believe that we can actually work 8 hours a day coding. I disagree. I burn out after some time. Understanding and modifying code takes a lot of energy. Doing it alone requires a lot of breaks. A naive calculation would say that one developer works 8 hours a day while two developers 16. So pair programming will make 2 developers work 8 hours. Obviously that is bad math because we are not robots, we are human. The more effort we do, the more breaks we need.

While pairing, much of the understanding effort is split in half. That means that my focus time goes up. I feel that I build things faster, I understand more and I build more when I have somebody to share the burden with.

New tools in your tool belt

When you work alone, there are very few new tools you start using. You will be at your constant pace. This might not look like waste until you see the alternative.

Your pair will not only join you with his or her ideas and memory, but with refactoring skills, browser addons, command line tools, IDE extensions, custom written bash scripts and a ton of other stuff. All of these will amplify your productivity. These tools will let you understand a problem better or change more code automatically. If pairs get switched often, the best tools will soon spread to the rest of the team. This is a huge productivity win for everybody.

Monitor your level of enthusiasm

When you work with a technology that is new to you, not using the correct tools, on over-engineered code and with a reviewer that constantly asks to rewrite stuff you will soon start to feel inefficient so your motivation will go down. This demotivated state will become the new default and you will not have any enthusiasm for new stuff. Add a cherry on top manager that wants you to be an agile full stack dev ops and you might end up just a demotivated dev in a demotivated team.

The benefit of working in a team, even in a team of two, is that once you have a challenge you cannot overcome, the other team member will jump in and knock it down. This keeps you motivated. We live in a culture where companies ask “how can we motivate employees more?” when in fact a better question is “what demotivates employees? how can we remove that?”. Working solo on software gets very demotivating in time, pairing removes that.

The dust has settled

Pair programming is not a new concept. It has been around for decades. I always felt I was more productive when pairing and I enjoy building software more. It seems that I'm not alone. The people in the team I work with feel the same. Your mileage might vary. When searching for a job, just make sure you value the same things as the team you will join.