The Modern Software Developer - Pair Programming is more about people than coding

Pair Programming

In last month's issue, we looked at sleep and how it can impact your mental and physical performance as a software developer.

You can catch that issue?here.

In this issue, we get a bit more technical?as I?share what I?think?about pair programming.

I'll cover:

?? What is it??

?? What are the benefits?

?? How do you do it??

?? When it works and when it doesn't...

But remember, we are looking at this not just from a programming point of view but from a mindset and wellbeing perspective too.

Disclaimer: these are my thoughts and ideas about pair programming from when I've seen it work successfully and when it hasn't worked at all.?It may?not align with what might be considered strictly "correct"...

What is it?

In my opinion, pair programming is not just two or more developers coding on a single machine, but is?more about taking joint responsibility for the outcome of a story, a task, a feature or even an app.

You might have already figured out that I'm not just talking about coding here, although it is an integral part of it.

As a pair, there is a lot to be done, making sure you're clear on requirements and discussing possible solutions, architecture and design.?

Then there's?writing tests, code, and documentation. And there could be build and release pipelines to create and more testing to organise...

You might agree between you that one developer scaffolds a new project?while the other goes to seek clarity on a requirement.

You might agree that one of you sorts out build and release pipelines while the other makes a start on some documentation.

?? OR, you might decide to collaborate on all of the above.

The key is to keep communicating, set small goals and then reconvene regularly if the tasks at hand are not strict pairing tasks.

Ultimately, you are collectively taking responsibility for delivering a story, a feature or an app, but?you can do some tasks separately.

What are the benefits?

There can be many benefits of pair programming when it is approached in the right way, which involves utilising it as a tool?within a?culture of trust, humility and autonomy.

The benefits include, but are not necessarily limited to:

?? Knowledge sharing.

?? Real-time code review.

?? Multiple perspectives that produce more robust solutions.

?? Keeping focused.

?? Having a?sounding board to bounce ideas off.

?? Faster onboarding of new developers.

?? Formation of closer relationships.

How to Pair Program?

With pair programming, there are primarily two roles, the driver and the navigator, and only one computer.?

The driver is at the keyboard writing the code, while you could say the navigator is thinking ahead and reviewing the code on the fly.

Some people have strict rules around what each of these roles should be doing, but for me, the relationship dictates this.?

For example:

The navigator might tell the driver exactly what to do...

?? Create this class

?? Add this property

?? Add xyz method...

And the driver can question this at any time.

On the other hand, the driver might start coding and explaining what they are about to do and why they are doing it... and the navigator can question this at any time.

?? OR, it could be a mix of the two...

And it doesn't have to stop there. You could pull in a BA, a product owner or someone from UX to clarify things on the fly as well...?

My main point here is that it can be as fluid as you need it to be, but if you both work better with defined roles and rules, then you can do that instead.?

You should have the autonomy to decide this...

When Pair Programming doesn't work

Some people think pair programming is?a ridiculous notion:

?? it's not productive; developers?could be working on separate tasks.

?? It's not for introverts and drains your energy.

?? Developers don't like people watching them code.

?? You're not adding value unless you're typing on the keyboard.

?? No one wants to spend 8 hours a day coding with someone else.

In truth, it can be ridiculous and doesn't always work.

Especially when we throw people together that don't have a good relationship or are not interested in forming one.?

It's no good forcing someone who is very opinionated and closed-minded to pair with someone passive and quiet.

Here are just a few reasons why a developer or a development team might have a bad experience with pair programming:

?? You have specific and strict EXPECTATIONS of what pair programming is (e.g. it needs to happen 100% of the time).

?? Someone has FORCED you to do it; it's not your CHOICE.

?? Someone is DICTATING when you do it and for how long (often too long).

?? You have an existing belief about how software development SHOULD be done and don't like to compromise.

?? You don't have a good RELATIONSHIP with the person you're doing it with.

?? You feel like you've lost your AUTONOMY.

Losing your autonomy, being dictated to or forced into doing something, being told?when to do it and for how long...?

...is going to cause a negative experience, whether it's with pair programming or any other endeavour.

When Pair Programming works

I'm a big fan of pair programming, but it's not a one-size-fits-all.

For me, pair programming should be fluid and used as a tool that a team can call upon when it makes sense for them to do so.?

But who decides when it makes sense for them to use it... they do!

This is essential if pair programming is going to make a positive contribution, and?for this to be the case, the team must have trust and autonomy.?

Mindset

Pair programming can be tough, which means your mindset and attitude are vital to your success.?

A great way to approach it is by thinking about what you can learn from your pairing partner.

Some core traits?will take you?a long way too, which might be different from what you might expect.

?? Empathy.

?? Vulnerability.

?? Compassion.

?? Losing your ego.

These are not necessarily the traits you would associate with your typical software developer, so they are worth paying special attention to.

You'll appreciate them from your partner, and you'll do well to return the favour if you want to make pair programming work.

You're going to:

?? Make mistakes.

?? Have your judgement questioned.

?? Have your knowledge tested.

?? Feel insecure.

?? Admit to not knowing things.

All of this can cause us to react in less than optimal ways, so it's a good idea to set some expectations from the start.?

For example:?

if you're pair programming in a language that you don't have much experience with, bring that to the conversation and let your partner know you might have to look up a bunch of things...

Also, you could make it clear from the start that looking stuff up is absolutely ok and won't be frowned upon.

If you both like to be the driver, agree on a timeframe for swapping roles.

Plan in breaks to give yourself some space and check your emails.

The Relationship

When pair programming works, it?isn't about throwing two or more random developers together for hours on end, it's about making the most of relationships.

There is a balance to be had, though. If two developers are exactly alike, they'll either both want to drive all the time or both want to be navigators. This is where specifying changeover times comes into play.

Likewise, if the two developers are too similar, you may not get the kind of collaboration you expect.

However, you get the biggest benefit when you have two developers with different perspectives on things. They come up with?different options for designs and solutions, and you get constructive challenge too.

It goes without saying that in this situation, developers must be willing to listen to each other and be prepared to compromise.?

That's why the relationship is so important.

The Human Factor

When pair programming works, it's often because there is a great appreciation of?the human factor.

We all must improve at treating each other as people first, developers second.

This is why autonomy and trust are so important; as humans, we all go through phases of high energy and low, have good moods and bad, feel confident or self-conscious, and feel sociable or anxious.

Expecting pair programming to take place for 8 hours a day or even at predefined times is not the way to make the most of this practice.

If for some reason, you're not in the mood to be paired up one afternoon, you should have the choice to say so and make other arrangements.

The same goes for when it would prove more productive to do tasks individually.

For this to work, it either needs to be ingrained in the team culture, or there must be a very good understanding between the developers in question.

Conclusion

I?think pair programming is great when it is used appropriately and without dogma. It's a tool that can work in some situations and may not be the right tool in other situations.

The mindset of individuals and the relationships between leaders and fellow developers are the biggest factors for making this work.

It's not a one-size-fits-all; if it isn't working for you, either change what you are doing or don't do it, be pragmatic and do what's best for the team.

Remember

It's not selfish to put yourself first; there's nothing more important than your own wellbeing!

If you found this interesting, please share it with your network.

Until next time...

How I?can help you:

Software Developers:

1. Start your own?Wellbeing Plan

2. Join over?7000 people and follow me ???Richard Donovan.

3. Mentorship on?MentorCruise.

4.?Mindset coaching

Software Development organisations:

1. Team?Wellbeing Health Check

2.?Developer Support Package