[n0us]

You're limited by the resources available to you on your local laptop and when you close that laptop the dev environment stops running. Remote dev environments are more costly and complicated to maintain but they can be shared, can scale vertically (or horizontally) on demand, can persist when you exit them, and managing access to various internal services from dev environments can in some cases be simpler.

It also centralizes dev environment management to the platform team that owns them and provides them as a service which cuts down on support tickets related to broken dev environments. There are certainly some trade offs though and for most companies a local VM or docker compose file will be a better choice.

[underdeserver]

Most local laptops are much stronger than is needed to run the entire stack of your average startup with no resource issues.

And the dev environment stops running when you close the laptop, but you also don't need it since you're not developing.

Not saying it can work for absolutely all cases but it's definitely good enough for a lot of cases.

[anthonypasq]

... this is an article about Stripe, not your average startup

[underdeserver]

And yet the discussion can go beyond that.

[giido]

Also tends to security advantages to mitigate/manage dev risks. Typically hosts will have security tooling installed (AV, EDR, etc) that may not be installed on local VMs, hosts are ephemeral so quickly created and destroyed, network restrictions, etc.

[crabbone]

Not even once did I want to share my dev. environment, nor did anyone want to share mine. We are talking about 25-odd years of being a developer.

Never in my life did I want to scale my dev. environment vertically or horizontally or in any other direction. Unless you work on a calculator, I don't know why would you need that.

I have no problems with my environment stopping when I close my laptop. Why is this a problem for anyone?

For overwhelming majority of programming projects out there they fit on a programmer's laptop just fine. The rare exceptions are the projects which require very specialized equipment not available to the developers. In any case, a simulator would be usually a preferable way to dealing with this, and the actual equipment would be only accessed for testing, not for development. Definitely not as a routine development process.

Never in my life did I want development process to be centralized. All developers have different habits, tastes and preferences. Last thing I want is to have centralized management of all environments which would create unwanted uniformity. I've been only once in a company that tried to institute a centrally-managed development environment in the way you describe, and I just couldn't cope with it. I quit after few month of misery. The most upsetting aspect about these efforts is stupidity. These efforts solve no problems, but add a lot of pain that is felt continuously, all the time you have to do anything work-related.

[marcosdumay]

I get a serious feeling that interpreted languages, monorepos, environment orchestration, snapshot ecosystem aggregators, and per-function execution evironments are all pushing software development into the wrong direction.

Those things are not bad by themselves. But people tend to do bad things with them, and those bad things spread remarkably well, disrupting every place they infect.

[crabbone]

I'm not sure why monorepos are in the list. Care to elaborate?

I've worked on projects that used a single repository for all the code written by different departments and projects where the same department could have multiple repositories. The later added insane amount of busy work, inordinate amount of errors, difficulty to investigate failures, excessive use of resources to house various permutations of systems created at different times with different combinations of components. The day-to-day in such projects could be described by developers waiting for the infra people to sort out the morning problems which mysteriously broke everything all at once so that no progress can be made.

This was in stark contrast to companies working on a single repository, where days when nothing worked would happen maybe once or twice a year.

I also lived through transitions from multiple repositories to a single repository and the other way around. In operational terms, I've never seen any beneficial effects of splitting a repository. Not in the short, nor in the long term. Complexity always went up, productivity went down, general satisfaction with project infrastructure would also go down with such a change. Department would start attacking and blaming the infra people for creating obstacles to their progress (while never explicitly mentioning the split repository because, usually that was a decision made by the same people complaining).

[marcosdumay]

Oh, yeah, all of those issues of enforcing transitive dependencies that need busy work to update, fluid APIs that make all the code around it break, lack of semantic boundaries that make it hard to decide if a problem is local, inter-component interference so that you have to select them perfectly well...

All of those are enabled by monorepos. And once people learn to do them, they seem to want to apply everywhere.

[intelVISA]

The absurd lengths people will go to avoid learning how computers actually work because they fell for the buy now, pay later promise of 'easy' development.

[otabdeveloper4]

> For overwhelming majority of programming projects out there they fit on a programmer's laptop just fine.

What? No. You live in a very sheltered world, my friend.

[crabbone]

Talking form a perspective of someone who worked at Google and one other similar company that shell remain nameless... as well as simply looking at places like Github where people tend to post projects they are working on: I don't know of any Github project that would be even in the size range to cause any discomfort for a laptop user.

Even when it comes to the larger projects: I have multiple checkouts of GCC and Linux kernel on my laptop, and when I run du their existence doesn't even register in the first dozen results... Of course, proprietary projects tend to be on a bigger side due to putting a lot of not-strictly code-related stuff in a repository, but still... it would have to be billions LoC big to be prohibitively big for a typical laptop.

[otabdeveloper4]

Good for you if you have a server-sized "laptop". (With the attendant heat and noise issues.)

Not something I would ever own myself, though, so don't generalize.

P.S. The issue is compiling and running all this stuff. Just doing a 'git clone' and nothing else isn't developing.