Code. with. me.

January 11th, 2021

Working remotely as a team has always come with its challenges and 2020 has catapulted many teams into exploring this space further. For us at Future500, the shift to full remote was not extremely large. We were in a position where multiple team members already worked from home 3 days a week. Even so, the investigation of more efficient remote collaboration was prioritized when we found a recurring theme of frustration in our retrospectives. This blog is about one aspect of remote collaboration that had eluded us for a long time: Remote pairing sessions.

In person, pair programming is one of the most effective ways of collaborating. We use it often, but found that it is a lot more tiring when sharing the screen remotely. We identified a few reasons for this:

- Directing the driver is more demanding.

Sometimes screens blur or stutter due to network connections. Not being able to point to the screen, or see when the driver is looking at the wrong thing adds a few layers to what needs to be verbally communicated. This lead to team members feeling more fatigued after a session (and thus resistance to pairing sessions).

- Handing over the keyboard is more costly.

When switching the navigator/driver role in person, it's a matter of passing along the keyboard and shifting mindset. But remotely, it requires switching who's sharing the screen and the current state of the code. Sometimes it requires committing and pushing something incomplete, which needs cleanup later. In our case, this barrier resulted in more one-sided pairing sessions (not switching driver/navigator roles as often) than before.

- Screen sharing itself affects responsiveness of the host system.

We're not sure what causes the problems, but multiple team members have had slowness in PHPStorm while sharing their screen (we use an in-house jitsi-meet server). While not directly related to remote pair programming, it was during those session that this problem bothered us the most.

How can we avoid screen sharing?

The common denominator in our complaints was screen sharing. When trying to solve this problem in the past, we had tried some tools that allows two parties to work together on code remotely. Think "Google doc", but in your own editor. While it sort-of worked, there were too many other issues in the tools that made us abandon that particular experiment. With the release of the Code with me plugin in PHPStorm, we decided to re-run our experiment.

It works by having a client app, which is not exactly your own editor - but close enough not to cause much friction. So the person initialising the session is still the one doing all the committing, but typing in the client is immediately available in the host and so you don't need to make such an explicit "switch".

The client (in their own color scheme):

Follow the leader

The most important benefit we've seen is that following each other in a pairing session is very natural. Some technical hick-ups aside (the product still needs some love for sure) we all preferred pairing through the code-wih-me plugin over traditional screen sharing. Navigation between files is way better than describing a location to the driver in words, having auto-complete on both end of the line is really nice. When you open a file, it is instantly also opened for the following party, and the file location ("Project view" in PHPStorm) is also shared. You end up almost always watching the same thing while still retaining control.

Video call included

The plugin currently also features a video call of its own. Which means that instead of setting up a call and then opening a pairing session, the pairing session will include the call (the technology is the same as we already used, the open source jitsi-meet server). That lowers the barrier of getting a second pair of eyes on your current problem even further, the only thing you need to share is a link.

Having the call as part of the editor's process also means that you have options depending on your screen real-estate at the time: if you have multiple screens, you can float the window and drag it aside - but if you happen to have a single screen, your video call can be docked inside the full-screen editor. Super nice.

The host sees:

Running the tests

The latest version of the plugin shows a terminal opened by the client in the host screen as well. Both parties can then see the output making it quite useful for running the tests or console commands. There is a security risk in allowing a colleague to run "stuff" on your machine (I'm having Rick Astley wallpaper flashbacks 😱) so for the paranoid folks like me the "read only" setting for the terminal sounds like a good idea. During our experiment, the terminal would only open if we gave write-access first. We'll just assume that is a bug and will be solved in an upcoming release.

So it's all good then?

Some features where still missing at the time of our experiment, most importantly the "search" functionality. Searching for text/classes is not visible to the other party, which means you can miss some context about what the other person is seeing. But this is a minor grievance.

Personally, I also miss a shared debugger window. I use XDebug quite often and while I can step through a request and have my pairing partner follow along the opened files and locations, the actual debugger window with runtime information like variable contents and watches is not shared. This makes step-debugging together more cumbersome than using screen sharing.

Furthermore, sometimes the connections where dropped, or the plugin was otherwise buggy. This is why the first improvement we would like to see is not new features but more stability.

Overall, we are all pleased and will continue to use the code-with-me plugin as part of the toolkit for remote collaboration. Hat tip to JetBrains for making our lives as remote developers a little better :-)

Ramon de la Fuente

Pointy haired boss