The ongoing COVID-19 situation has forced us all to dramatically rethink how we work, with many industries struggling to adjust their on-site procedures to ensure the safety of workers, and many more adapting to support much of their workforce in working from home. As a largely computational research group, we are incredibly fortunate in our ability to carry out most of our work remotely, and our department’s wonderful IT and administrative support staff have enabled a smooth transition to remote working.

Despite our relatively fortunate position, working remotely isn’t always straightforward, and everybody has different home circumstances that will affect their work. For some, this has meant having to juggle family and work life; for others, the sudden loss of human interaction is a very real concern. Some may lack a suitable space at home to work comfortably, while others may simply not have an IT setup comparable to what they are used to.

Regardless of our personal circumstances, the current situation has necessitated rethinking how we work, and exploring how different tools might help to address our needs. Previously, I’ve written about running Jupyter notebooks on remote servers and streamlining SSH use to make remote working more convenient. What I didn’t cover was how to effectively interact remotely with a large code base, where just SSH’ing in and using Vim might not cut it. I’ve tried a few different solutions, each with their own strengths and weaknesses. Today I’m going to talk about my current favourites, Atom and Virtual Studio Code.

Atom

I’ve been a fan of Atom for quite a while now, and it’s usually my go-to recommendation whenever someone asks for editor suggestions. Atom is relatively lightweight, cross-platform, open-source, with seamless git and GitHub integration, and the new Teletype package is a promising option for teaching and collaborating on code remotely. One of the big draws of Atom is that it is able to be customised to suit a wide range of uses. Syntax highlighting and code linting? There’s a package for that. JavaScript consoles and Jupyter kernels? There’s a package for that. Editing code on a remote machine? There’s a package for that. Several, in fact. I’ve used two such packages – remote-ssh and remote-edit – and was able to edit remote code from my laptop as if I were sitting in my office at work. Well, minus the company of course. This versatility, however, can also be a weakness, as it takes some time to explore the packages available to find the setup that works best for you, and there’s always the risk of your favourite package dropping into ‘no longer maintained’ limbo. If you’re willing to spend some time experimenting, and don’t mind occasionally switching packages out as new options become available, you can customise Atom to do just about whatever you need.

Visual Studio Code

Ah, Visual Studio. All-powerful Windows development environment, and all-consuming hogger of system resources. I’ll admit it took me a while to start playing with VSCode due to my mentally associating it with Visual Studio and its reign of terror on an old Windows laptop, but I’m glad I finally did. Much like Atom, VSCode is a free, lightweight, cross-platform editor with git integration, and a diverse ecosystem of packages with which to customise the editor to suit your needs and tastes. One place where I’ve found VSCode to shine is in performance – where some releases of Atom have suffered from performance issues, I’ve found VSCode to consistently run fast and leave my resources free for me to commit inefficient code sins. What’s really cool in this world of remote working is its Remote Development extension pack, which provides support for three different cases of remote editing: on a remote machine accessible via SSH; inside a container; and inside the Linux subsystem on Windows. This last option is particularly nice to have if you use Linux on your work system and Windows at home, and want to stick your work setup on your home machine without worrying about dual-booting Linux or spending all of your time in the WSL.

Other toys are available

Of course, there are plenty of other options for editors (and memory-hungry IDEs), and at least as many opinions on which is best. I don’t want to tell anyone what they should or should not use, as we all have slightly different wants and needs. Instead, if you’re looking for a better remote working experience, I encourage you to explore the range of options available. For many of us, fully-remote working is a new challenge that will take time to adjust to, but also an opportunity to experiment with tools and technologies that we might not normally consider.