 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
My friends know I’m a bit of a car nut and a gearhead. Guilty as charged. I love to tinker. I love being under the hood. And when I am on track, I know why a car moves the way it does — and what I can do to improve or modify any parameter.
My car is my kingdom, my happy place. For that reason, even if you gave me the steering wheel to the Formula One RB19 that Max Verstappen drives and told me to give it a whirl, I’d be in heaven, but only for a while. Driving that car would be fun, but it would also be more dangerous for me. I would probably feel overwhelmed by the performance and would struggle to get the feel of the machine.
And that’s why I really, really don’t want an online integrated development environment (known as a cloud IDE). The cool kids of the tech world are starting to push for the cloudification of the last bastion of local Ops — the IDE. While Visual Studio Code has been hybrid for quite some time, the newer versions like GitPod and Cloud9 have a much more opinionated version of the IDE. As in, zero local software. Zero local memory. Zero control. I can customize within the parameters of the IDE, but that’s quite limited compared to all the ways I can customize my local development environment.
In other words, I can only run Nix in the cloud. Nix to that. Here’s why you will have to pry the IDE steering wheel from my cold, dead (gloved) fingers.
Like a chef’s kitchen or a mechanic’s bench, your local IDE is a sacred space tailored to your comfort. I appreciate this even more as a weekend road warrior who thrives with grease under my nails. Sure, we all need the shared classes of tools and capabilities for a complete and productive developer experience. But the IDE should never be a one-size-fits-all piece of software. We need our custom keybindings, plugins, scripts, CLI tools and all the things that make us comfy with our coding. The cloud is a step in the wrong direction. Here are three reasons why.
There are many tasks that you will always want to run locally — formatting, linting, unit tests, build tests and all the “boring” stuff that’s no fun to run locally but is even less enjoyable in the cloud. Imagine being queued up behind a cloud CI/CD system with a massive list of jobs. You’ll feel like a Formula One driver stuck behind the safety car.
Outages are rare, but they do happen. Whether it’s a DDoS attack, a problem with core internet infrastructure or spotty coffee-shop Wi-Fi, running local means you’re never held hostage by these unexpected mishaps. Just like a Formula One driver having a spare front wing at the ready, you can keep working without a hitch.
Running a local IDE may seem more complex. In reality, it’s the same complexity as a cloud IDE — except you control it. Your DevEx team may still want to limit tool choices and control versioning so that everyone is looking at the same basic set of tools and outputs so that testing locally is still broadly applicable across the entire team or organization. However, that’s a far cry from being forced into rapid, massive cloud IDE switchovers.
Call me old school. Call me a cloud Luddite. But I will never choose to develop software using a cloud IDE. And please, please don’t even think about taking away my local IDE to “synchronize” my development environment with the rest of the team.
I understand why platform teams are attracted to reducing choices to put in place guardrails. We talk about that quite a bit ourselves here at NGINX. But a cloud IDE is basically like forcing me to sit in a cockpit that is alien and uncomfortable. I will be slower, make more mistakes and spend lots of time waiting for CI/CD jobs to run somewhere in the vastness of the gloaming data ether. And when the inevitable crash comes, my cloud IDE will choke and grind to a halt in a cloud of virtual smoke as I wait for the cloud mechanics somewhere far away to fix my ride.
