Recently, the founder of we’re-going-to-reinvent-the-terminal startup Warp wrote a blog post about why it’s taking so long for cloud integrated development environments to catch on.
I don’t disagree with Zach Lloyd’s assessment: Development remains one of the few digital spaces tied to physical machines, and there are serious benefits to writing and running code in the cloud.
Lloyd points out that version control — a major factor in cloud adoption for many knowledge workers — isn’t a motivator for developers to code in the cloud. Although that’s true, I think there’s a deeper reason why developers aren’t moving to remote development.
My evolution to a cloud IDE
I’ve been a grumpy UNIX admin for a very long time. Early in my career, developers were using editors like BBEdit, Sublime Text, or, later on, Atom. In the meantime, I didn’t really know what environment I’d be working within from day to day. I’d be on my laptop today, sure — but tomorrow I’d be connecting over SSH to a recalcitrant Solaris box, and I knew remarkably little about Solaris. But I did know that it’s UNIX and that it’d have some form of vi installed. So I started using vi as my default text editor, having given up on using GNU nano (which is a fine editor, but in those days it would get you made fun of, and I used to have thinner skin).
At that point, it started feeling pretty weird to have a fairly expensive laptop and more or less run it as a terminal. That said, an awful lot of laptops are glorified Facebook and Twitter machines, so I had nothing to worry about comparatively.
Those early days also predated Docker. Getting an application to work on Mac OS X was usually doable — it was, after all, a certified UNIX — but it was not fun. Even today, the behavior of sed on a Mac versus a Linux box is markedly different until and unless you install GNU sed on your Mac.
On one particularly irritable afternoon of work, I threw my hands in the air, thought “screw this, I’m over it,” spun up a virtual machine on a server in the data center, and used that as my development box. Suddenly, my dev environment looked a heck of a lot more like production. It had a super fast connection to the internet. As an added bonus, my accident-prone self knocking a drink onto my laptop didn’t destroy data that I cared about anymore.
I was hooked.
How I code today
Fast forward to 2022, and I still largely follow this pattern. I’m writing this post while taking a break from working on code for a project, somewhere midair above Denver, from my iPad. It’s the only computer I usually bring with me on trips these days, just because the remote workflow is so ingrained in how I think about things. Anything code-centric or requiring heavy lifting that’s not a good fit for an iPad-based workflow lives on a Graviton EC2 instance in us-west-2, while the iPad provides me what’s basically a thin client: little more than a keyboard with a screen attached.
But getting other people on board with my cloud-based development approach goes over about as well as if I suggested they smack a baby platypus in its bill or something.
These days, I bias toward using Visual Studio Code (please do not email me about how wonderful it is, as I already know). But despite numerous attempts, I can’t find a way to make VS Code work comfortably for me in any other scenario than on my desktop at home. GitHub’s CodeSpaces goes a long way; Blink Code integrates VS Code into itself for a more native experience. But there’s just something about the ergonomics that doesn’t work at all for my use case, so I’m forced to reexamine exactly why so many of us push back against cloud-based development.
Current options for cloud IDE
Microsoft and Amazon have certainly tried to drive toward cloud-based development. Google hasn’t really, given that it’s mostly satisfied with Google Docs as an IDE. (“Wait, what? Who writes code in Google Docs?!” you might reasonably exclaim. The depressing and sad answer is “engineers being interviewed for roles at Google.” It’s a part of the interview process that I can only assume is rooted in some archaic form of hazing.) It should be noted that at the 11th hour Google dropped their new Cloud Workstations offering in preview. It offers a bunch of supported IDE options (including, somehow, vim)–but I haven’t tested it yet.
I was very interested in exploring Cloud9 shortly after AWS acquired it. The product had some iPad teething issues that did get solved. For me, the hurdle was always gating access to my development environment behind a high-friction process: First, log into the AWS console and navigate to the right service and subsection. Combine that with what felt like a high degree of being opinionated in ways I disagreed with (for instance, the concept of not having a persistent working environment by default), and I was turned off. I haven’t heard much about AWS Cloud9 in recent years. I know there’s a service team dedicated to improving it, but I’m not seeing it in the wild at all.
On the other hand, CodeSpaces is getting a lot of attention, and I’ve been sporadically using it for some projects, myself. It’s nailed most aspects of the user experience, the pricing is eminently reasonable, and the sign-in process is very low-friction. And yet …
I find myself reverting to my tried-and-true process more often than I’d like: “SSH to an EC2 instance and use vi to edit files.” It’s based on nothing else I can point a finger to beyond “habit.”
Cloud IDEs will take off … when the experience is worth it
I think that’s really what our development choices come down to across the board: habit.
By the time someone is working professionally as a software engineer, they’ve been writing code long enough for habits to form. Their ways of working are more or less ingrained. For something else to supersede that habit, it needs to be enforced by policy (which doesn’t tend to go over well), be a technical requirement, or be such a significantly better experience that switching is a no-brainer.
Unfortunately, the experience of cloud development, while periodically better on a variety of axes, hasn’t been a transformative breakthrough from the developer experience perspective so far. Until that changes, I suspect driving the adoption of cloud-based development environments is going to be an uphill battle.
At least, for now, everyone will have top-of-the-line laptops.
