The certain situation the world has been in for the past almost two years has affected a lot of us devs all around the globe. This hasn't stopped us from delivering amazing software and do good deeds though - Au contraire! Think of global remote hackathons, local efforts to create services that help people in need, providing schools with old laptops, the list goes on.
Arguably, the tech industry has adapted rather quickly. Video calls became a widespread norm, employees of some companies, like Twitter, can now work from home forever if they want.
(As a little disclaimer: I'll use the word "remote" in this post to describe non-onsite things in general, even if you're in the same town as your peers.)
With the new remote situation came a few hurdles, though. And in this post I want to discuss some of these hurdles, and more specifically, how to overcome them. A specific topic I'd like to look at today is pair programming.
Pair programming is a very helpful technique. It helps to onboard new team members to an existing application, give juniors an opportunity to learn from more senior devs (and vice versa!), discussing ideas and concepts. A popular approach to pair programming involves two roles: A driver and a navigator. While the driver is doing the actual coding, the navigator tries to keep the overview and give directions to the driver. Both people get to discuss their ideas and find the best solution together.
From my experience, two people are usually working on the same computer. They come up with a plan together, write down open questions and then get going. I've done this with peers for weeks on end. However, the remote situation has made pair programming rather rare, at least in my team. It can be rather tedious. Screen sharing works, don't get me wrong, but it's easier to point on something on screen with your finger than to figure out the lines (and read them aloud at the same time!) of some blurry editor while the other person is scrolling along. I've played around with IntelliJ's pair programming feature for a bit, but not everyone uses IntelliJ either. For me, coding together on the same machine still feels a lot more productive.
So, what are your experiences? What tools do you use? What are your best practices when it comes to remote pair programming?
I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️ or a 🦄! I write tech articles in my free time and like to drink coffee every once in a while.
If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!
Top comments (7)
Zoom is by far the best tool I’ve used, even if it’s slow. Still very hard to not let the host drive more often.
Cameras are a must. You lose a lot in communication when you’re not able to read facial expressions while you explain something. And seriously, AirPods are not a substitute for a microphone.
I had to learn to announce my intention to use the mouse/keyboard before doing so. This made it easier to highlight code rather than “pointing” to it verbally. Probably a good habit even for in-person pairing.
I tried the VS Code sharing tool probably 2 years ago and wasn’t very impressed. As nice as the idea is, pairing is more than just looking at the same IDE.
Never did any proper remote pair programming, but throughout the years I've done many coding sessions over discord, skype, etc. with people giving them introductions to programming and stuff. Fun times.
We're using Discord voice rooms so we can play some music in the background while coding, and use VSCode pair-programming tool. Tried Code With Me (JetBrains IDEs, eg PHPStorm/WebStorm) but didn't seem mature enough at the time. Will give it another go soon.
Pair programming more than 4 times a week for the last year (had to onboard 2 new developers). It appears to be a great timing that Slack releases their Huddle feature with Screen Sharing and Drawing. (Lets be honest, I don’t need to see their faces to debug something and I hate Zoom - disgusting UI, slow to open, not intuitive, etc.)
I came up with a review-based workflow with our Junior engineers: issues are discussed together via zoom (it also allows to annotate shared screen or record the session) and then I let the juniors work until the PR is ready.
Static issues (regression, lint) are catched up by the ci so we can focus we the review on what's the most important: exchange knowledge. Often the review (using GitHub review function for PR) is a two way discussion rather than me simply checking the code. It is also done via Zoom while sharing the screen with the PR review page open.
The Juniors explain what they came up with and why and I will comment on that and try to provide best practice solutions, in case there is one (design pattern, specific algorithms etc).
If the topic requires further explanation we often lookup resources together and discuss what they are about.
During all this we take comments with the review functionality on where we agree to change things. The PR is then not necessarily updated only by the juniors but also by me or both of us.
To keep things expressive we try to include many comments in the code, often we find those places that require extensive documentation during the sessions.
In the end we do a squash merge. I know this is far from classic pair programing but it turned out for us to be very effective in working on code AND exchange knowledge.
I know that Slack's video calls offered some kind of "draw on the other person's screen" function, that was off by around 100 pixels in each direction. We used it a couple of times, but it never really worked as well as we thought it would.
Cool idea!
Thanks a lot. I will think about it in near future.