DEV Community

Kamau Wanyee
Kamau Wanyee

Posted on • Originally published at

I tried pair programming

I recently completed my undergrad and had some free time on my hands as I applied for jobs. I was a little bit low on motivation to work on side projects or tinker with new technology. As a substitute, I got into watching Twitch coding streams and was intrigued by the concept of mob programming with the chat. I felt like that was something I would like to try one day, baby steps though. I reached out to my friends to see if anyone was interested in hopping on a call to pair program on a project they were working on. Luckily I found someone willing to experiment with me. They were working on a tourist destination Flutter project. The first session went well enough that we had another.

My friend has a blog series on the process of building the "Places to Visit" Flutter application. If you are interested, you can check it out here.

Here are a few takeaways I got from my experience pair programming:

Concepts are transferrable among languages

First of all, I know nothing about Dart, the programming language used in Flutter. However, that did not put me at a disadvantage to derail my friend's productivity. We did a quick overview of the project he was working on. I got a quick crash course on the structure of a Flutter application. After that, we were off to the races working on the next feature in the application.

Due to syntax similarities with other languages, I was able to infer what the majority of the code was responsible for based on the context and usage. I am comfortable with using higher-order functions when dealing with array manipulations. A quick search if there are map and filter functions in Dart and we were able to refactor code for better readability. I was happy to have some input even though I was in a foreign space. It should not be a surprise because languages are just tools we used to solve problems. Several principles guide the problem-solving techniques, the languages simply offer a representation of those techniques.

It's a win-win situation

Pair programming is a collaborative exercise, so you get to learn a lot from each other. People think and approach problems quite differently. Both parties need to be open to providing feedback along the way. The extra pair of eyes is really helpful when they catch things you miss along the way. This definitely reduced the debugging time when things went wrong. You also realize someone's thought process informs the way they code. Understanding how they think helps you phrase things in a way they will understand faster. This makes communication way easier. You learn a lot from each other.

Your code is not your identity

The collaborative nature of pair programming means there will be a lot of back and forth feedback. Essentially your code may be under scrutiny. You have to remember to not get attached to your code and be defensive about it. Acknowledge good suggestions and have an open mind about the criticism. You can provide the reasoning behind your decisions to validate your method. You have to remember that it is not an argument on who is right or wrong. You are not your code, feedback is not attacking you as a person.

Readable code makes collaboration easier

What is considered readable code is sometimes nuanced but there are definitely objective pointers on what is considered readable. The less the mental overhead for me to read and understand the code, the better. So definitely bespoke long one-liners are not good for readability. They may be good for codewars katas to flex your skills but not in a codebase meant to be consumed by others.

I know naming things is one of the hardest things in programming, but try and make your functions and variables informative on what they are responsible for. It makes things a whole lot easier for others to understand the codebase. Future you will also benefit largely from naming things contextually.


Tools have come a long way that it has made remote pair programming quite effortless. It can be easy as hopping on a video call and sharing your screen. Tools like VsCode, like their share extension, have extra features that make code collaboration better. I highly encourage people to try out pairing more often. For teams, it can help form bonds and synergy that helps with collaboration and productivity. Remember to have fun while at it. Share stories and crack jokes, it helps break the monotony of writing code.

Top comments (7)

cosmasnyairo profile image
Cosmas Nyairo

The pair programming session were highly beneficial... I got a chance to see how tests are written and the huge difference they bring to the work flow if they are implemented earlier in the project. Hope to join in on another pair programming session soon!

cchana profile image
Charanjit Chana

I was very resistant to the idea of pastor programming but it took minutes for it to become a tool I would look at with great respect. I was around the mid-level in my career at the time and first paired with a very senior developer. He had patience and helped to bring my skills up in the few weeks we worked together.

It’s quite obvious to me now, that the code in a project will only be as strong as the ’weakest’ out last experience developer. By pairing up, and rotating those pairs, you bring everyone’s skills up and the same should happen to the code.

Unfortunately, I haven’t worked in many roles since that alex for pair programming. I’m hoping I can change the mentality around it in my current position.

masharsamue profile image
Samuel Mashar

alafu ukaskia openings za junior devs pale si unipeleke na rada naivisha react na redux na node backend. Wagwan kibroski

lexlohr profile image
Alex Lohr

Since we write code to be understood by others, having someone with you who does exactly that while you code for immediate feedback is really advantageous.

w3ndo profile image
Patrick Wendo

I have got to do this too soon. Seems eye opening!

skylee91 profile image
Sky Lee

Is there any platform or website to find a stranger for pair programming?

w3ndo profile image
Patrick Wendo