How to Strengthen Your Team with Pair Programming

A growing team is a blessing and a curse.

New people bring fresh ideas, which is great! But new people also bring new ideas, which might not be so great. Every time we grow our team, the entire dynamic of how we work together inevitably changes. This process is well documented and sometimes called "Forming, Storming, Norming, Performing."

Thanks for reading Function Pointer Newsletter! Subscribe for free to receive new posts and support my work.

In my experience, there is only one way to onboard individual software engineers, and it's amazingly powerful.

It's called pair programming. You do it from day one, and you don't stop once you get started!

Reframe your understanding of "productivity"

"Pair programming is so inefficient!"
"Isn't it a waste of time to stare at a single screen together?"
"I can't work with someone looking over my shoulder all the time!"

Set aside your preconceived notions about the so-called productivity impact of sharing a single screen and having only one person do the typing. Pair programming is collaboration in its truest form, and it unlocks a higher level of productivity.

What is productivity, really? The number of lines of code produced, the number of JIRA tasks opened, or the number of code review comments posted? These things are parameters of (busy) work, at best. True productivity is about coming up with sustainable solutions to business problems. And non-trivial work always benefits from collaboration. When you work on a problem together, the solution is always superior. Software engineering is rarely a solo game.

Pair programming is a powerful collaboration tool that deserves its place alongside individual work. By working closely together, you will actually save time, not waste time. You will double-check each other's work organically and skip the back and forth of code review.

Two minds are better than one.

Show them around the place

Show, don’t tell.

When onboarding a new team member to a software engineering team, a lot of ground needs to be covered in a short amount of time. In this early phase, simply showing them around like you would a new house can be an effective opener and conversation starter.

That's precisely what we need when re-forming a team: conversation. The conversation should be about more than our superior technology stack, immaculate software architecture, or our predecessors' historical decisions (mistakes 😈). It's also about integrating this new person's skills and ideas into the project. Behind the smoke and mirrors of tech, software is an elaborate mental model, a blueprint of winding hallways and rooms that lives in the minds of all who maintain it. It's dynamic and ever-changing.

Don't underestimate the impact of the first few weeks with your new developer friend. This is where you get the chance to establish a base for your new collaborative relationship. Spend enough time in this phase and show them around the project.

Invest in welcoming your new team member.

It's invaluable for their future contribution to the team.

Shoulder to shoulder

Get right to work and share your screen, always.

Working from home or not, this should be the basis for your first few weeks together. Have your new coworker tag along with everything you do so they can get a feel for the day-to-day.

Yes, just work. Start a task you would have typically done alone and work on it together. At first, you'll want to be in the driver's seat so you can explain how your team generally approaches this kind of work.

What are the best practices, and how did you settle on them? Keep an open mind toward their ideas on these practices. You could learn a thing or two.

Brief them on the types of code review questions they'll most likely get. Explain the review etiquette if your team has any.

Walk them through the software's architecture. Take the feature you've decided to work on as an example, and go from high-level to low-level in a vertical slice. A wider purview is probably too overwhelming and detail-oriented at first. I like to go one feature at a time. As you work on features together over the next couple of weeks, the bigger picture will come into focus.

Don't go too fast.

Once they feel somewhat established in the project, it's time to turn the tables on them and hand over control. How fast you can do this depends on the project's complexity and your coworker's confidence level, but do so in week 2 if you can!

From then on, you become the sidekick, letting your new companion steer the ship. Keep your hands off the keyboard as much as possible. Just think and work together, see where it takes you, and evaluate after a couple of weeks.

Eventually, you can decide to split off and pair with someone else, do some individual work, or continue pairing indefinitely. Most likely, you'll settle on a mix.

I like to alternate between individual and pairing work. It depends on the type of work, but I aim for one or more pairing sessions per week.

Pair programming improves team cohesion and generally yields better code.

Will you give pair programming a go?