Microverse Fast Track Program — What Remote Pair Programming is Like
Reflecting on my first week in a new coding boot camp called Microverse that focuses on remote pair programming and sharing my impressions.
First of all, what is remote pair programming?
It is when you and another coding partner live in different cities, you can be on opposite sides of the globe really, and you use teleconferencing to work together to solve coding problems. You can see each other’s screens and you are connected via audio so you can discuss freely on-the-fly to organize ourselves and talk your way through our problem solving thought process.
This works better than you might think
and comes with many benefits compared to coding solo that might not be immediately apparent until you’ve tried it. The only real technical issue that I’ve run into is that you need to be wearing headphones as there can be an echo that sometimes distorts the voice chat.
Driver and Navigator
We generally work from one Github repository that we are both collaborators on. And one of you is the “driver” and the other is the “navigator”, which means that the driver has all the files on their local computer and does the coding, while the navigator sees the driver’s screen to visually follow along and provide their input. The navigator will also be doing research and finding answers from various resources such as StackOverflow.
And throughout a day you will switch to take turns being the driver. Each time you switch over, the code must be re-committed to the shared repository so that it always holds the most up-to-date code, so that the other can then continue the progress from where it was left off. There is even technology being rolled out now in modern IDEs where you can both type at the same time from your separate keyboards to the same local file. This comes in handy for quickly sharing a small idea where doing a full switchover of roles would not be worth it.
A lot of developers and organizations are catching on
to the many benefits that come from this way of coding in pairs. They are even finding that it actually provides productivity increases that outweigh the fact that two people are working on one task, even if it sounds counter-intuitive at first.
It means that there is a second pair of eyes to catch errors such as typos. An alternate way of thinking to tackle a problem from a different angle, or just give you confidence that your own idea just might work and is worth pursuing. You will have a greater pool of strengths that you can collectively pull from.
I also found that I can code for a lot longer this way too
The fact that you keep switching throughout the day reminds me of how I used to change my riding position when I was biking across Europe. Over a long day when my muscles would start to get sore, I would modify my position through the day, such as I would lean over a little further, change my grip, or pedal more with the heels of my feet rather than my toes. Thus I can get other muscles to do the work while my main ones took a bit of a break. Switching between being the “driver” and the “navigator” feels like it lets me use different parts of my brain, thus giving it more endurance for longer periods of time.
It was recommended to us that we switch every 20 minutes. Apart from this creating a lot of practice in learning git commands, as you are constantly uploading and syncing the code on the shared repository, we found this frequency to be too high. Instead we typically go anywhere from 30 minutes to as much as a couple hours before switching. Sometimes one of you is just “in the zone” where you have very clear thoughts on where to go next and the code is just flowing from your fingers and you are better to take advantage of this bout of inspiration and energy. When one of us is feeling tired or stuck, that’s been our cue to make the switch.
So I can say that my first week has been very promising and I am looking forward to what kind of progress I can make over the next several more weeks and months!
