Pair Programming, Trio Programming, Sextuplet Programming?!

Unless you are a spider, it is hard to throw more than two eyes on your code all by yourself. (I get entangled in my code from time to time anyway 😉 ) So once in a while, I can hear a "Woah, dude. What is this?" from the desk next to mine. Followed by another "I don't think your method is even called at all". I slide my swivel chair to the baffled colleague.

And 💥! You're in a pair programming session.

2

Looking at colourful lines of algorithms together is not something you necessarily have to plan. (Although all agile teams probably jot that down as a must-have action point at least once every month.) It just happens. It's in the nature of what you do. Gosh, you wouldn't use Git if it weren't for others. Remember when you did Pull Requests on a repository you're the sole contributor to? Oh, those insta-merge-times!

So, be ready for some dinner for two. Actually, it is a feast, a feast for experiences and learning. As countless of developers before me have pointed out: You learn more by explaining your use of Promises or what other wizardry you can do. Not only as a beginner. Explaining is double the learning - that is true magic!

Some of my tricks to make this experience even more rewarding are those which make sure both have a common ground to work with. Making a quick sketch on paper to visualize the software architecture? Insights - yes, please! Reformulating things that were explained and new to you? You got it!

Even the smallest things can surprise some of the most experienced programmers. Switching from a method to its test in IntelliJ Idea without touching the mouse can raise a "Wait, how did you do that?" and promotes shortcuts that can save time for all!

As social as it is, often we can lose track of time and space. Sometimes, we are intensely discussing and generating code that we don't notice the disruption we create for the rest of the team. This is especially the case when you get along with your fellow reviewer and joke around and gasp synchronously at every compile error. So, be aware that other people's workflow can be disrupted. (That's why I am for free noise-cancelling headphones for every dev in the world! 🎉)

And all that hustle and bustle can attract other predators. 😉

3

Then, a third programmer joins the battle! My code is under attack by two professionals! (Which I am thankful for as I have a lot to learn.) As a Junior, it is actually quite interesting to be quiet for a while and listening to two developers debating. You get to know the lingo, how to talk about code, how to analyze and structure your thoughts in a meaningful way.

It turns into another thing when three Seniors get together. Those debates can get hot tempered but also very revealing and inspiring. It is probably like a three-roomate situation. When you get along, everyone is winning. But unfortunately, this constellation favors 2-to-1 majorities which can tip the scales.

Therefore, in threesomes I tend to play the listening part. When explaining happens, only one should do it with potential additional remarks at the end by the third person. Otherwise, it can get confusing. Maybe, it is time for a whiteboard session. But as you know: Three people drawing on whiteboards can lead to craning necks...

6

I know that my code can look like a car accident. But I did not know that it attracts as many rubbernecks as a real one. Meanwhile, five other developers stand behind me and watch my Annotations do weird stuff. For people outside the bubble, it must look like I am successfully hacking into the FBI database. (Which I don't.)

This situation does not occur too many times. But when the problem is significant and hard enough, it could attract plenty of viewers. And this mass can work as a whole and crack the nut. I noticed that these gatherings do not take too long. Not only do some colleagues lose interest, it can make all of us unproductive when sitting around one table for just one specific bug.

Thus, last time I reviewed my findings with a handful of other excellent colleagues, I had screen-recorded the execution steps beforehand so that I do not stumble upon unforeseeable errors and waste anyone's time. Or replacing verbose curl commands with a GUI-like Postman setup. Making your work comprehensible for several is more tricky than having the time and focus to convey it to one person.

Nevertheless, it is a comfortable thought that enough people care for your problem. Willing to group up with you. In these moments, I feel the team energy and capability that we all long for!

1

At the end of the day, everyone returns to his or her own screen. You can take a break or go home or start another flow just for yourself. Other than most meetings, I come back to my desk with confidence after a pair programming session. Having been productive albeit not having produced a lot of lines of code.

That is also a funny side effect to all that duo, trio and sextuplet coding. Cherishing your me-time!