Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
The Pros and Cons Of Pair Programming
Lessons From My Summer At Menlo InnovationsPhoto by Gemma Evans on Unsplash
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!
Follow me on Twitter and Instagram to stay up to date with my content!
The Ultimate Guide To Pair Programming was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.