Lessons From My Summer At Menlo Innovations
Many programmers are skeptical about pair programming: The agile software development technique in which two programmers work at one workstation.
This is the type of feedback I often hear:
“That seems like a total waste of money because you’re writing half as much code as two programmers, on separate computers.”
Or
“I’m an introverted person. I would hate to have to interact with a partner at work constantly.”
These are fair concerns. I might’ve shared these opinions before working at a pair programming company.
See at my last job — software development at Menlo Innovations — you’re not allowed to write code by yourself. If you’re working on production code, you need a partner.
And after working with them for a few months, I’ve drank the pair programming kool-aid. I believe in many situations pair programming is an amazing way to tackle different tasks.
Here’s why.
The Pros
#1: Pair-Programming Reduces Towers Of Knowledge
“Towers of Knowledge” or “Top Performers” are some of the biggest threats to productivity on teams.
Towers of Knowledge know the entire codebase like the back of their hand. They’re the person the team calls on when they need a feature rolled out ASAP or a massive bug fix.
Towers are problems because teams lean on them too heavily. Towers often become bitter at their work environment because they’re pestered with questions all day. Extra work is thrusted upon them (even on weekends). Once towers decide to quit, it puts the company in a bind because no one knows the codebase like they do.
Towers of knowledge are dangerous, self-feeding loops. Because many other programmers are asking them for help, the towers get the opportunity to see, think about, and work on more of the codebase than anyone. This further increases their intellectual dominance on the team.
Towers hurt team morale because programmers feel insignificant standing next to them. Additionally towers slow the team to a stand-still when they call in sick for a day.
To makes matters worse, business writers and tech writers often cite the wrong solution to this problem.
When you read everything from Lencioni to Theil, they all have war stories where they fired or demoted their top performer and instantly their team morale shot through the roof. They say it was difficult to readjust without the tower of knowledge at their disposal, but team morale is much more important. End of story.
This a flawed business philosophy. Not only it is bad form to punish your best performer for trying to add value to the team, but very quickly teams will develop a new tower of knowledge.
The correct solution is to pair the Tower of Knowledge up with another programmer!
This makes knowledge transfer seamless. If you have another programer working with the tower all week, then the tower doesn’t have a monopoly over that knowledge.
They might still be your best performer, but there will not be negative side-effects when the top-performer calls in sick or decides to leave for a different company. The tower’s pair programming partner will be able to relay the crucial information points to the rest of the team.
If you mix up who pairs with the tower of knowledge week to week then every programmer will share a piece of the crucial information and feel important to the team. Thereby increasing team morale.
#2: Pair-Programming Makes Onboarding Awesome
Because knowledge transfer is so seamless under the pair programming method, on-boarding becomes easy.
New-hires don’t have to do week(s) long “training camps” or follow an out-of-date environment setup guide.
New-hires just get assigned a pair programming partner and start learning!
Under the pair programming model, new-hires have a constant role model to work under. They will learn about the codebase very quickly, and start producing value for the company much faster.
New-hires often struggle with context of the codebase, but not programming knowledge. Veterans are solid on context but are sometimes tempted to cut corners to get their tasks done faster.
These two figures can balance each-other out.
(Truth be told, new-hires often want to cut-corners too. But veterans are held to a higher moral standard and often try harder when under the microscope of new-hires).
Either way, new-hires are worse than worthless for the first month on the job. They suck value away from the company until they know the context of the codebase. Under the pair programming method, new-hires have the opportunity to start producing value for the company on day 1.
#3 Pair Programmers Produce More Than Twice The Code Than Individuals and Pairs Are Great For Introverts
Let’s be honest here, the majority of the time programmers spend at the job isn’t actually writing new code. It’s debugging, it’s strategizing, it’s testing, etc.
If a computer scientist’s job was to write 10,000 words of gibberish a day then sure, it would be faster to stick two different programmers on separate computers and have them start typing away.
Thankfully, computer science is not that.
The majority of the time we spend at the keyboard isn’t typing, it’s thinking.
Debugging is an exponential time-wasting affair. If someone on the team knows the solution to an error, debugging can take seconds. If no one on the team knows the error, it debugging take anywhere from minutes to hours to days.
Having two programmers at one workstation means that teams are twice as likely to know how to fix a problem as soon as they encounter it. It also means programmers are more responsible about asking for help.
If two people have to agree with each-other before asking for the help of another pair at the company, this means they will not over-ask for help. If either of them have an idea on how to proceed, they will attempt to do so before calling in back-up.
They will also not under-ask for help. When a single programmer is spinning their wheels on an issue, it’s not obvious he or she should ask for help. After all, they could just be one Google-search away from an epiphany. However if a pair of programmers is stuck on an issue, then it’s quite obvious they should ask for help.
Pair programming is great for introverts. 80% of programmers at Menlo self-identify as introverts. Still, they love the pair programming method. Why? Introverts like people who are on the same page as them.
Pair programming partners are thinking about the same things, examining the same code, and asking the same questions as each-other.
This kinship isn’t just healthy. It’s fun. It’s morale-boosting to not be alone when faced with tough programatic issues.
That said, pair programming isn’t perfect.
The Cons
#1: Pair Programming Can Complicate Simple Tasks
If you have a very simple bug fix or a straightforward feature to implement, it can be expensive to put two programmers on that task. Additionally it can be hard for two programmers to stay interested on a task that takes minimal thought-processing power. If you have an environment with a large test suit or integration process, pair-programming can further increase the resource expenditure.
I would argue this is where pair programming struggles the most. Simple tasks can be overcomplicated by pair-programming.
It really does depend on the pair though. Sometimes, having a pair partner can boost morale when working on a simple task.
#2: Pair Programming Doesn’t Totally Eliminate Towers of Knowledge
Many pair-programming authors over-hype what pair programming does for towers of knowledge. Some suggest that pair programming is the “silver bullet” to cutting them out. I agree that pairing helps this issue a lot but in business I’m hesitant to claim anything is a true “silver bullet.”
On teams, there will always be people that hoard important knowledge. This isn’t malicious, people naturally gravitate towards that objective.
Pair-programming doesn’t eliminate that human trait. There will always be programmers that find a way to monopolize information.
I still maintain that pairing towers of knowledge up with other teammates is a better solution than villainize-and-fire-the-top-performer which is another popular solution to this issue.
Firing the top performer might be a good short-term fix, but in the long term it disincentives employees to do their best.
While it doesn’t eliminate the problem entirely, pairing is the best long-term solution to the tower of knowledge problem.
#3 Pair Programming Holds Employees Super Accountable, Sometimes Over-Accountable
At Menlo, many employees say they leave work feeling “brain-dead.”
They claim they think harder and longer at Menlo than at any other job they’ve ever had.
This is because it’s impossible to slack off when you have a pair programming partner. Having a teammate that’s watching you all day, keeps you super accountable. It’s hard to cut-corners. It’s hard to “tune-off” at work.
This is good and bad.
Obviously it’s important to stay focused at work. However, I’d argue it’s equally important to take mental breaks, and re-evaluate solutions.
That’s why at Menlo, they make sure programming pairs are taking breaks throughout the day. In the morning, Menlo employees do an activity called “stand-up” where they share what they’re going to be working on for that day. In the afternoon they do an activity called “walkies” where they walk around the block.
These mental breaks and activities are paramount to successful a pair programming culture.
How To Implement Pair Programming at Your Workspace
Sold on pair programming? Want to give it a try? Well you’re in luck.
The good thing about pair-programming is that it doesn’t need to be an all-or-nothing technique.
At Menlo, they made the strict business decision to have everyone code in pairs. But it doesn’t need to be this way. If you work at a company that is more traditional, it’s quite possible to pair up with a co-worker to accomplish just one important task.
Another idea is to partner up with another programmer for one iteration if you’re working under the Agile development model.
These half-measures are a great way to give pair-programming a trial run without committing too many resources. You can then compare the effectiveness of the pair compared with individual results at the company.
If you’re going to try one of these measures, I would recommend pairing on complex, mission critical, and lengthy tasks as opposed to simple, non-important, and short tasks. The rationale is that the former gives long-term recurring benefits and showcases pair-programming at its best.
If you do give pair-programming a try, let me know in the comments how it works out! I would love to hear success (or even failure) stories of this exciting new development technique!