Useful tools: USE Together - Remote pair programming made easy

The current COIVD-19 pandemic has shocked the world. For developers, like myself, it means that we’re working from home. Working from home is not an issue for me personally. I have an office, a good chair, reliable internet and everything an office has except for the people.

Just because I don’t face any issues does not mean others doesn’t. One thing that has been blatantly clear is that junior developers might struggle a bit more than usual. They are separated from the senior developers which usually gives them guidance. Junior developers must explicitly ask for help rather than tapping the person sitting next to them on the shoulder.

We saw this happen early on and wanted to nip this problem in the bud before it escalated. Our solution was pair programming. My current employer has two services for screen sharing: Microsoft Teams and Slack, either of which does a terrible job as a pair programming tool. Slack for one doesn’t allow remote control, which in of itself is a deal breaker. Slack also has a tendency to blur text, which makes the whole process more difficult.

Microsoft Teams looked like a viable option for a little while. It has screen sharing and remote control, which is excellent. It does fall short when it comes to transferring keystrokes. If we work within multiple applications one cannot alt tab. I often use keyboard shortcuts in Intellij which is being completely ignored by Teams. I cannot be productive if I were remote programming through teams, and I doubt anyone else can either unless they primarily do everything with the mouse.

In my last post I also mentioned the other issue: Intellij. Don’t get me wrong, I love Intellij as an IDE. It is clean, it has sensible keybindings, it is extensible and malleable to my liking. What it doesn’t have is a good way for remote pair programming. There are plugins which make remote pair programming happen, but from what I can see they force us to either set up our own server or upload our code to their service. First is bothersome, the latter is a risk.

I went out looking for a few options, with a few criterias:

  • Application agnostic: Not being tied to one specific application. The tool doesn’t need to support the entire world, but it must support a few.

  • Respect the codebase: We do not want to upload our code base to various servers.

  • Be secure: Obviously.

  • Be easy to use: We don’t want to set out workspaces and configurations for each module and system we have. 

In my search I discovered USE Together, a remote pair programming tool developed in France. Let’s go through my requirements and see how it matches with USE Together:

Application Agnostic

USE Together are, basically, just a screen sharing tool - but it is a really good one. This means that it is not tied to any applications whatsoever. For example VS code’s Live Share is really good, but it is also very much tied to VS code. If I want to jump to SQL Developer, Postman or any other application to demonstrate or test something, it simply won’t work. Since USE Together is just a screen share we can do whatever we want.

Both Teams and USE Together share many of the same features. Multiple named cursors, being able to talk to each other and remote control (of course). What USE Together excels at is how it deals with keyboard shortcuts. I no longer feel limited when I am working on somebody else’s computer. It is not as smooth as working locally, and such a solution never will, but it is good enough. The added freedom that I can pull up documentation and go through it with a junior developer is just great as well.

Respect the code-base

I am basing this on USE Together’s white paper, I am assuming they are telling the truth in this and they have given no reasons to doubt that.

What USE Together says hey are primarily peer-to-peer and their servers mostly function to validate licenses, handshake conversations and so forth. They are also bound by GDPR in this regard, so I assume that they are not lying either. This means that the actual data shouldn’t go through their servers (unless you use their browser version I assume). On top of that, even if it did it would be through an encrypted image of the code, not the code itself.

In short, USE Together respects our code. We keep it on our local machines and our git repo.

Be secure

This is a tough one, because it is hard to verify that something is absolutely secure. Referring back to the white paper though I cannot see any major issues. The peer-to-peer technology fills me with more confidence that a centralized attack will yield little results. In any case we are streaming images of code, so even if parts managed to get attacked I doubt that much value could be extracted.

I’d say it is good enough. I have no reason to doubt the security.

Be easy to use

USE Together is as easy as calling someone on Slack or Teams. Just call the person you need and you’re there. When the application has been installed it needs no setup. By being a screen sharing application we avoid much of the hassle which some other plugins bring.

So yes, it is very easy.

I like USE Together and I like how it works. It is not perfect and has a few quirks. Being peer-to-peer is great, but it limits the number of people who can attend a call and the quality of the call very much depends on the host itself. Is screen sharing the best option and the future of remote pair programming? Not sure, but right now USE Together does a great job.

Previous
Previous

Don’t use transient fields

Next
Next

The importance of unit test names