What is pair programming?
Pair programming as a general practice is in its infancy, but the concept has been around for some time. It started with John Von Neummann in the early 1900s. He asked others to review his code, and since then there have been a number of research papers and books written on how to do it effectively.
Pair programming is often a topic that makes people shudder. It places people in vulnerable states as someone else peers over their shoulder as they work.
If you loathe the thought of pair programming, I can relate. When I first started pair programming, it was frustrating and stressful. However, after pair programming regularly with over 10 people for a number of years it eventually grew on me. And, as a result, I've experienced the long-term benefits of this technique.
In this article, we'll cover the benefits of Pair Programming, the different styles used, techniques to mentor well, and some helpful tips to set everyone up for success.
The benefits of pair programming
Here are some specific benefits of engaging in pair programming.
Prevents knowledge silos
When every member of a team has that few things they are really good at, it creates knowledge silos. Life happens - so if someone is ill, takes a vacation, or leaves the team, it leaves the other developers on a team with a large knowledge gap.
It is also important to understand how other parts of a project work together, as it can give better insight into how what you are working on affects the bigger picture.
Builds better relationships
When you work singularly on projects, it can be easy to isolate yourself from the people you work with. Add in the ever-increasing option to work remotely, and it's easy to go days (even weeks) without really interacting with your team members. Pair programming gets you involved with other members of your team, helping to build better relationships with one another.
Expands your knowledge
"You don’t know what you don’t know.” There is so much to know in this industry that it is nearly impossible to know everything. Even when you think you have something completely figured out, boom - a new update. Sure, you may be the mentor...but there is also the potential for you to learn something from the junior developer.
When you explain how to do something out loud, you in turn learn there are things even you didn’t fully understand. Plus, the learner may not understand the first way you explain something. So having to communicate differently in order for someone else to understand requires you to really understand the topic well...and to re-examine your understanding of it if you’re struggling to explain it.
Two are better than one
On that point, two minds are better than one. Two sets of eyes give more opportunities to keep an eye out for errors, bugs, missteps, and refactoring opportunities. It really is helpful to have a second perspective.
No shortcuts
When someone is watching you code, you are less likely to take shortcuts, which - no surprise - produces better code.
Pair programming styles
So what are the different styles for pair programming?
Ping-Pong
- Both parties have comparable skills and knowledge backgrounds
- Common practice is to pass the keyboard or screen back and forth
Presentational
- Mentor is the driver, takes on a more of a teaching role
- Learner takes the backseat, and observes the mentor
Driver’s Ed
- Mentor is the navigator, giving guidance to the learner
- Learner takes the wheel, doing more of the execution
Barriers to mentoring
Remember playing with legos? (hey, maybe some of you still do)!
Whenever we built our ultimate masterpiece, it took a copious amount of time and we beamed with pride at our creation. If anyone wanted to touch it or change it… no way! You were possessive of it. And if someone wanted to give input halfway through, it could feel as though it wasn't yours completely.
We've all had a thing that we don’t want to share with anyone else in the world - our most prized possession. That thing we waited forever to get or the thing we worked really hard to make.
Why don't we want to share?
- We don’t want others to break it
- We don't want others to change it - no longer feels like ours work
- We don't want to feel ashamed of how much we care about something
What does this have to do with the developer world?
Well, code is treated by developers like their most treasured possession.
- If someone changes it, it doesn’t feel like ours anymore
- If someone is looking on while we are creating, we feel vulnerable
- If someone starts picking it apart before we’ve had a chance to parse through the logic...emotions rise up. We start to feel sad, angry, and even overwhelmed and panicky.
See the similarity?
Our code is really not all that different to our lego creations.
So how do we move forward, and overcome this barrier? Let's take a look at some techniques we can incorporate into our mentoring journey.
Techniques to mentor well
Many times, people mean the best. No one sets out to intentionally offend someone, or cause tension. But there's a lot that a mentor can do unintentionally in a pair programming duo that can negatively affect the learner. By making a few adjustments, mentors can improve the success of the person they are mentoring.
Don't creep
Have you ever noticed that you misspell words more often when someone is watching? Or trip over your words, or lose your place?
Be mindful that the person you are pairing with is nervous. It's going to take time before they are comfortable working with someone watching them. It can be especially nerve-racking if you’ve never paired before.
Think back to the very first time you did pair programming. It may have been challenging to work with someone peering over your shoulders - watching your every keystroke, commenting when you misspelled something or forgot necessary punctuation. If it wasn't fun for you, it's not fun for them.
Let them drive
As developers, we are makers of things - we are doers. And as doers, it is hard to take a back seat and take on the role of the teacher instead. Because in order to figure out a solution to a problem, we typically figure out by trying, failing, trying other things, and finally (hopefully) succeeding.
As a mentor, it can be difficult to convert your thought process into words. It seems logical to make yourself the driver, and figure out the problem so you can show the learner how to do it, right?
But when we do this, we take control of learning out of the learner’s hands.
It slows the entire process down, for a few reasons:
- By introducing multiple screens, it can be hard to keep track of all the steps
- If you take over and start trying to explain, the learner may not get everything you are saying - everyone processes words at different speeds
- It's hard for the mentor to know if what they are teaching is actually being understood, because people do not feel comfortable speaking up when they don’t understand something
Yes, it takes longer. Yes, they will take the wrong turns. And yes it requires a lot of patience. But…letting them make the mistakes, even though it’s a bit like watching a train wreck happen, is exactly how they learn for the long haul.
Encourage questions
Have you every wondered why sometimes it's so hard to speak up? To ask questions?
One explanation is that it’s an automatic confession that we don’t know something - we view asking for help as a sign of weakness. Everyone else seems to know how to do it, so why don’t we? Or maybe we’re afraid someone is going to think less of us for not knowing. In our industry, our knowledge is often seen as our status.
A simple approach to combatting this is by encouraging questions.
Don't ask:
- “Do you have questions?"
Do ask:
- What questions do you have?
- Do you remember how to do…?
- Should we go spend more time going over the background for...?
These encourage dialogue and further learning, rather than putting someone on the spot to come up with a question, or to bury their insecurities by asking no questions at all.
A big step is to also lead by example. Don’t being afraid to let others see you ask questions or research things when you don’t know something.
Give good directions
As a mentor, there is a lot of internal logic happening - but it isn’t always shared.
Do I go right?
Do I go left?
Do I turn around all together?
So when the mentor is driving, it can be difficult for someone who is not knowledgeable about the subject to follow along and understand all that is going on and why.
Think about getting driving directions - how difficult is it to follow someone’s directions when you are unfamiliar with an area? Now imagine the person giving directions changes their mind halfway through, and says to take a different way instead. Talk about disorienting...odds are very high you are going to get lost.
Now change the scenario to an area you are comfortable in, like your neighborhood. If someone starts giving directions and then changes their mind halfway through, you can easily reconfigure the path.
Explain the why
Laying out the path from thought conception to completion is vital in teaching problem-solving. When that is hidden from the learner, they don’t know how you got from Point A to Point B. For instance, when we sit down to figure out a problem, a lot of paths are considered, most of which are wrong. But we don’t discuss these wrong paths, because...what is the point?
But being wrong is half of the learning process.
It's helpful to ask:
- What was it that initially made you think that path was a viable option?
- How did you determine that it was actually the wrong path?
It is difficult to go back and explain that thought process afterward. Because all of these steps and turns are important to solving problems, developers need to know why certain decisions weren’t a good idea - so when it fails, they understand why.
Strengthen their confidence
Here's a scenario - the mentor and learner run into a code problem. But instead of working through it together, the mentor figures out the problem on his/her own then tell the learner what to do. How confident will the learner feel, being cut out of the whole process? Not to mention, it feels a bit like cheating - being given the answer, without doing the work.
No one wants to call something their own when someone else did it for them. And frankly, it feels pointless for the learner to duplicate the work that the mentor just did. You can build the learner's confidence by letting them problem-solve alongside you.
It's not always easy
Have you ever used these phrases when teaching something new?
“It’s really quite simple.”
“All you have to do is…”
“Just go here and do…”
“It’s pretty easy.”
The word “simple” is defined as something that is easily understood or done or composed of a single element. However, when we do something for the first time, rarely is it ever simple. It's easy to use this description in an attempt to make something less intimidating.
But when you’ve been told that something was easy - and it’s actually not - that is even more intimidating and can make you feel like you're not capable. It also feeds into Imposter Syndrome that is prevalent in the developer industry.
Imposter syndrome
Have you ever been given a task that you know very little about - and suddenly feel like you know nothing in comparison to those around you? Thinking things like:
- “I should know this...why don’t I?”
- “What if someone finds out that I really don’t know that much about this?”
Or have you received a compliment about work you’ve done and felt like you just didn’t deserve it? As if there are others out there that are more deserving? Did you chalk it up to timing, luck, or maybe that you had secretly conned those around you?
Imposter Syndrome (aka Fraud Syndrome) is feeling like you:
- Are a fraud
- Don’t deserve the success you’ve achieved
- Know so little in comparison to those around you
It's surprising the number of people who relate heavily with imposter syndrome - especially senior developers and engineers who don’t feel like they deserve the recognition for the things that they have achieved.
Yes, our work is challenging. But be mindful not to downplay the complexity of it. It can go a long way in reducing the imposter syndrome that someone may be feeling.
Be transparent
Don’t be afraid to tell them when something is challenging - to tell them that it took you years to understand something fully.
You did not learn everything in one day, one month, or even one year. It was a process to get to where you are now. It can be comforting to know others have struggled with the same concept and it can go a long way in relieving any stress or anxiety that they may be feeling.
Empower them
When a learner is able to do the work from start to finish - how to get from Point A to Point B - they are given an opportunity to make mistakes and learn from them. When no steps or hidden logic paths are left out, they have everything they need to make an informed decision.
Think about how empowering it is to be able to finish something that you started, to learn from your mistakes, to see progress, to learn new tools, and to become more independent and confident in your skills. As the mentor, you can make that happen.
Tips for a successful pairing session
Send materials in advance
Send some helpful articles or tell them what to research before pairing up if you can. Having some base knowledge will make the learning process go much smoother - not to mention you will have less to explain, making the time together more effective.
Plus, providing materials in advance will make them feel more confident in having some knowledge of the new thing they are learning.
Take breaks
It is easy to burn out - for both parties. Mentoring takes an immense amount of patience, and learning takes a lot of brainpower.
It's helpful to aim for at least 1 break every hour, to keep everyone fresh and focused.
Let them make mistakes
While it is hard to sit there and stay quiet when you know why something is broken, making mistakes is pivotal to the learning process. Try to give them the opportunity to figure it out on their own.
If you need to, write it down so you can get it out of your system or refer to it later.
Communicate
As the mentor, it's on you to take the lead on communication. Ask if they are struggling to understand something. If you sense confusion, try rewording what you are saying. Sometimes simplifying a concept or relating it to something they already know can help.
And realize that there are a lot of words that a junior developer has not heard or does not understand yet. Using overly complex terminology can make a concept that is already challenging to understand seem nearly impossible.
Keep it simple. There will be time for the industry jargon later.
Set realistic goals
While it's tempting to have big aspirations, try to get through smaller chunks of logic. This gives more time to explain why you are doing something and allows time for questions or extra practice.
Understand their learning style
Knowing how a person learns is important when teaching new skills. Many of us are likely a combination of these styles, but we all lean toward one as our dominant.
Visual Learners
This group learns best when they able to reference images, videos, articles, etc. An example of this would be giving materials for them to review ahead of time.
Auditory Learners
This group learns best through listening to the information - think podcasts, lectures, and one-on-one conversations.
Kinesthetic Learners
This group learns best through note-taking and going through the motions of a particular task. For them, these activities help the knowledge stick.
Encourage questions
"You don't know what you don't know." Simple, yet true. As the mentor, you don’t know if they don’t understand something unless they tell you they don't know. Building the habit of encouraging questions at the outset will help provide a transparent environment.
Have them do their own research
At the end of the day, you can only teach them so much.
If they are going to be successful engineers, they have to be willing to go out and find the answers for themselves.
- Point them to Google, StackOverflow, or GitHub research papers and articles. If they struggle with finding their own, trying giving them links in the beginning. There is a treasure trove of information out there.
- Encourage them to mess around with the code, to make changes. Let them know, as long as they are on their own branch in development, they can’t break anything.
- Encourage them to look at the Source code to see how it works.
And if you have special tricks you do to learn something new, share that with them - you never know if it may work for them too.
Pair programming tools
Here are some good screen sharing applications for pairing remotely or between desks:
No lagging issues, and you can use multiple screens for camera image, screen sharing, and chat.
Offers chat/video conference, and can be integrated with Google apps like Calendar or Drive.
This platform is all about integration, streamlining meetings and creating fewer emails for all.
In this tool, both people have the ability to control the screen at the same time.
Become better together
Pair programming isn’t just about the coding - it's also about building relationships with your team members and learning how to work together. If we can empower our team members by making them more successful, we help build a stronger, more cohesive team.
More pair programming resources
How To Deliver Value During Pair Programming
What makes one pair programming session better than another? Check out these discoveries and observations.
Best Practices and Tools for Managing Remote Development Teams
Working remote is the norm now, but mentoring from a distance can still have a big impact.
Level Up Your Development Team With Better Agile Retrospectives
A lot of the techniques covered here can be applied and implemented during future retros.
