Hacker News Reader

Comment by simonw | Hacker News Reader

I go back and forth on this.

On the one hand, maintaining local development environments that work reliably across larger team if developers is a HUGE cost in terms of time and effort. Developers are amazing at breaking their environments in unexpected ways. It’s common for teams to lose many hours a week to problems related to this.

So I love the idea of cloud-based development environments where, if something breaks, a developer can click a button on a website, wait a few minutes and have a fresh working environment ready to go again.

But… modern laptops are getting SO fast now. It’s increasingly difficult to provide a cloud-based environment that’s remotely as performant as a M2 or M3 laptop.

View on HN

Two thoughts:

* in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production.

* building a cloud-based development where someone can refresh it automatically means you’ve identified a reliable process for installing and configuring everything. That same process can be run locally, probably using the same container definitions for everything except the parts they’re focused on.

If you've never seen good developers bork their local environments then you clearly haven't worked on a large enough and complex enough project.

I worked on a large project that needed to support development on many platforms. The amount of scripting for the git hooks and build hooks alone required its own development team. When subtly incompatible changes in git hooks rolled out, you would see a few people that ran commands in just the wrong way to bork their repository. These commands are usually fine, but when combined with an otherwise invisible change in the hooks, would just break things. Now the actual breakage rate was low, like 1 in 1000 in a given month, but with as many developers as were working on this project that was always a couple of people that had to nuke their local repo from orbit (it's the only way to be sure).

Note that I’m specifically referring to breaking it in a way which is significantly harder to recover from than rerunning a known setup process (Simon’s comparison to a cloud environment where you could reset it on-demand). It’s not about never making mistakes, it’s about having a good conceptual understanding and habits around configuration management.

> in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production.

I mirror this sentiment.

Another one that I've commonly seen: a bit of a yellow flag if a developer is struggling with Git. Becomes a red flag if the issues continue to happen after training. Usually means they don't understand other technical fundamentals.

A lot of developers struggle with Git. The only reason I don’t is because I’m interested in version control (too much according to some people I argue with).

Well I say that I don’t struggle but I’ve never had to use submodules.[1]

[1] Torvalds: people say that submodules is hard to use. True. But it’s gotten better now/it’s getting better. (Google Tech Talk 2007)

For me it comes down to how often something is holding you back. It’s perfectly reasonable for someone to only use the core Git operations, but if they’re losing work or having trouble collaborating that’s when I start to expect them to recognize that and try to improve.

Devbox aims to solve this very problem: https://www.jetify.com/devbox

What about local development precludes having a consistent, repeatable development environment? At worst you can distribute an environment the same way you would on the cloud.

In practice, the number one way to bungle a previously-working local environment at many of my past roles has been "brew upgrade". The number two way was to have MacOS and at least one Linux distribution used for local dev on the same team, but one vastly outnumber the other.

While I am very pro-containers as a deployment target I am also very resistant to containers in the critical feedback loop of local dev, chiefly due to iteration speed and performance/battery overhead, which was much more glaring when the Intel chips were all we had.

I can't endorse Nix in any capacity these days but it did seek to address multi platform environmental consistency, without containerization as your LCD.

I firmly believe MacOS and linux should be considered as different as windows and linux from the point of view of platform support. If the only time your software runs on MacOS is during development, you're probably wasting your time supporting another platform, and your developers are never developing against the target. "It's POSIX so it's the same" is a lie in basically all the ways that matter, you'll have a much easier time with a VM (by which I mean developing in the VM, not building a whole new VM/container in your development loop)

(And I don't think I've ever seen a dev macOS setup that could be called clean, but it's been a long time since I've interacted with that, so maybe the situation has gotten better since then)

My problems went away the day I decided to run a Linux VM for MacOS. With Parallels (and the others) you can have a good dev setup and still run the other tools (slack, email,...) on MacOS.

With local development the user has an almost unlimited array of other things they can do that might break stuff.

With cloud, they can't. They could drop their laptop out of a window and still be up and running productively a few minutes later (given access to a computer with a keyboard and a web browser).

> the idea of cloud-based development environments where, if something breaks, a developer can click a button on a website, wait a few minutes and have a fresh working environment ready to go again.

Until the cloud development environment inevitably breaks, and your entire development team’s productivity drops to zero.

This can and does happen with local environments too.

Ideally both options would be available using a wrapper that ensures consistency across CI, cloud dev and laptop dev environments but I havent had that luxury anywhere.

> This can and does happen with local environments too.

Absolutely—but when it does, it’s not evenly distributed. Some of your team can remain productive. Some can pair up. On the other hand, when the cloud development environment goes down, you always send your dev team home for the day.

Right, but you can have a dedicated team working on preventing that from happening - including robust automated tests that exercise the cloud development environment itself, checking that newly launched environments come up and work as they should.

I assert that such a team will be a lot more productive than the exact same sized team dedicated to local development support instead.

can you have a central conda install? or zip a full conda env?

with nixos, you can have a single default.nix and serve from a binary cache.

Docker makes it really easy

This. Locally, we run the apps/services in our IDEs and all the supporting infra runs in Docker via docker compose: messaging systems, databases, caches, etc.

This has the added benefit of ensuring that developers don't interfere with each other during development. Your Kafka messages will only be picked up by your processes. Your database changes don't impact anyone else until they're pushed.

If only that were true. Source: several years of supporting other developers working with Docker-based local development environments.

It certainly helps, but there's still SO MUCH that can go wrong.

Depends on how convoluted your infra is.

Reply on news.ycombinator.com