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.

Conclusion

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.