5 ms·

Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022.

Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, to a remote container + open shell with our app running? The technology is simply too complicated for us. We will never see such wonders in our lifetime." And I would say to you: take courage. If you believe in yourself, and maybe with some luck, it might be possible for you to do development remotely, like every server admin has been doing over telnet and ssh for over 30 years. Maybe in another 30 years, we will have gained the technological insight to be able to figure out how to have a team full of people to work on a single server at the same time, all connected to a network over an internet connection, with some crazy interface that keeps their shell session alive even if their internet disconnects. A man can dream...

yencabulator 4y ago
Working in a remote forest is actually pretty pleasant. Offline matters.
trevor-e 4y ago
fwiw I know some FAANG companies (Google, Meta) have already transitioned to remote development machines that do exactly this.
politician 4y ago
Why is it a good thing to give up remote development for a centralized solution?
- throwaway892238 4y ago
  I dunno, man. Some "dev ops" jerk at work is always complaining about how he has to spend all his time answering support requests from developers with errors in their local environment. It only takes like a couple hours of my week, so what? And then when our deploys fail because the server didn't have the same version of python as our local environment, he tries to blame the fact that the local and remote environments are different! Can you believe the nerve of that guy? Keeps trying to convince us that a single centrally managed system is easier or more reliable (or whatever) than 30 randomly configured ones on multiple operating systems! I think he's nuts, personally. I have half a mind to tell my manager that he's trying to disrupt our ideal workflows. And really, what's the problem with testing my app in an environment that isn't the same as production? Yeah, sure, I might save some time not having to maintain a local environment that everyone on my team can replicate. And, sure, developing remotely would let me change laptops without spending a week to set everything up again; but it's only a week, I have a ton of those left. And yeah, maybe the cloud network has a bunch of services that I need proxies and VPNs and other things to test from my laptop. And granted, doing development on a server with 40 CPU cores and the same network as the database and webserver is faster than my laptop. ...But if all that was better, I'd be doing it already. If it's on my laptop, I know how it works. What's better than what you already know?
  - politician 4y ago
    This is nonsense. We support a dozen developers running fully baked local development environments along with cloud-based dev, staging, and production environments. Multiple heterogeneous environments is normal. Granted, we don’t run any node, python or Ruby, because yeah I don’t want to spend all of my time debugging monkey patching bugs.
  - maxbond 4y ago
    That sounds like a problem that can be solved with a CI/CD system and Docker Compose. Perhaps there is more going on here institutionally that stops this problem from being solved. It sounds like something really frustrating is going on though, and I hope it works out.
    - maxbond 4y ago
      Hey I'd like to expand on this a little bit. I hope I'm not presuming too much but as someone who recently had to leave their job due to burnout, I feel like I'm seeing signs of burnout here, and wanted to bring them to your attention. You sound really frustrated because you're being asked to do things that you feel aren't or shouldn't be part of your job, and perhaps it's taking time from your other responsibilities and creating a larger workload for you. It seems like maybe you've come to resent your coworkers and their individual preferences for the complexity it creates and the stress it causes you. It seems like what you want to do is erase that complexity, take away their agency, and centralize on a solution that works well for you. There's a couple of things to consider. For one, what you're asking is for your coworkers to have a degraded work experience so that your work experience can be better, which is totally understandable but not reasonable. Another one is that this is a pretty well understood problem with known solutions - why is it you can't get them implemented? Is there something going on in the politics or culture of your workplace that is stopping you? Is there some kind of elephant in the room, and would things get better if you called it out? The last one is, are you getting burned out? Were you always this frustrated? Should you take some time off? Should you start looking for other jobs? I can really feel the stress and frustration in your tone, and that sucks. I hope things get better for you.
minitech 4y ago
> Maybe in another 30 years, we will have gained the technological insight to be able to figure out how to have a team full of people to work on a single server at the same time Why is this desirable?
- xvector 4y ago
  Lightweight terminals with days of battery life while a juggernaut handles the real work.
  - deleted 4y ago
    [deleted]
  - legulere 4y ago
    But we already have notebooks with battery life for 2 work days which have very good performance like the M2 macbook air. And I highly doubt that it's the cpu that is the limiting factor for battery life and not the screen.
    - pksebben 4y ago
      not to mention, horsepower is hardly ever the choke these days. I would say that the greatest limiting factor here is the lack of screen space, because now your dev must context switch to read documentation etc
maxbond 4y ago
If that workflow works for you, that's awesome. As a lifelong Linux user who works primarily in the terminal and uses a terminal based editor, it would work for me too. Dismissing people who work differently as being cowards is a stance I hope you'll reconsider. Dictating to people how their workflow should look - _that_ is the antipattern. Developers should choose their OS, their editor, and virtually everything about their workflow. Forcing them to work remotely robs them of the opportunity - you can work graphically over SSH, and you can use SSH from Windows (if that is your preferred OS), but it's a hack that isn't always going to work quite right and is going to create unnecessary friction for people with different workflows than you or I. That's to say nothing of auxillary tools, like debuggers, that people may want to bring to bear. Don't get me started on getting debuggers to work over SSH, yes it can be done, yes I have done it, no I don't ever want to do it again. The infrastructure should bend to conform to the developer's needs, and not the other way around. Generally technology should conform to the needs of humans, and humans should not be asked to contort themselves for the benefits of technology. For instance, at my last company, I was asked to use a Mac laptop so that the team could standardize on Mac. I complied to be a team player, and this turned out to be a mistake. It robbed me of so much efficiency in the first few months, and it never worked as well for me as Debian running on my personal laptop, which cost a _third_ of the price of that Mac. I had so many frustrating issues and things that just never worked properly. But for other people, it was a great choice; I have no interest in bashing the Mac - my point is that people should be allowed to choose and customize their own tools.
- fragmede 4y ago
  > Dictating to people how their workflow should look - _that_ is the antipattern. Developers should choose their OS, their editor, and virtually everything about their workflow. I'm not convinced it is. Back in the day, each developer had their workstation (not laptop) configured just so, with their own pile of `doit.sh` scripts to tickle the system in just the right way, to get things to compile and render and send it off to production. But we're no longer there. Developer velocity is a thing companies take seriously, so developer workflow is actually important to them, and standardizing one true editor as the supported editor means that all the developers get improvements whenever the internal tooling team does a release. And I'm saying this as a vim person who's tried to move over to VSCode (and have failed so far). Of course, smaller companies don't have an internal tooling or developer productivity team, and thus allowing people to choose their own tools is optimal. But I've also seen the big picture efficiency loss that results from every developer having a bespoke configuration thats intelligible only to themselves, and the inability to unilaterally improve people's tooling and integrations with various systems they interact with. Once the team gets debugging over SSH working or whatever, they can just deploy that, in a working state, to everyone. There's a world where Slack is the one true communication method and everyone is on a Macs. Unfortunately for me I'm set in my ways would rather use Ubuntu on a Thinkpad with vim, but that doesn't mean I haven't see that other world.
gitgud 4y ago
> Maybe in another 30 years, we will have gained the technological insight to be able to figure out how to have a team full of people to work on a single server at the same time Single repository, yes. Single development environment, no. Development environments should be isolated, so developers don't step on each other's toes... Also, centralised cloud development machines are by definition, a single point of failure, with small gains in consistency in development experience... > all connected to a network over an internet connection, with some crazy interface that keeps their shell session alive even if their internet disconnects. You know what's better than this? Not relying on the internet connection at all!... Decentralized development on local machines is simply a better experience and relies less on a giant cloud infrastructure
- quickthrower2 4y ago
  And tools like the one that spawned this HN discussion are going to help homogenise things and make it easier to go local.
denkmoon 4y ago
I've certainly had internet outages where I've continued to work on my laptop. I can't even imagine how expensive it would be to run like this. Sharing an environment is a _terrible_ idea, you need isolated environments.
bigtunacan 4y ago
It's unpopular because it's a terrible idea. Just because it's easy ssh'ing into the box, doesn't mean you should. Twenty years ago we didn't have the tools to do anything better. And while I miss some of the simplicity of those times I don't miss when someone ssh'ed into the server and fucked something up and left us in a lurch. If you really think this is the best approach today I really hope you aren't working on any critical systems.
- ithrow 4y ago
  It's for dev systems not production.
pmontra 4y ago
That is how I and everybody else were developing software at my university around 1990. A few HP servers, character terminals or X11 servers. Then everybody got a Windows desktop at home powerful enough to work as on those X servers and it was game over. I never saw a company developing on a shared server. Do you work for one doing that? In that environment I expect developers to need separate environments not to stop all the team in case of mistakes. Let's say: docker containers running on the server instead of pulling an image locally. I don't see much of a gain. Personally I could use my emacs to edit files of the server, my terminal to ssh on the server and my browser getting pages from there. For people using IDEs, those IDEs should either work in a different way or be in a remote connection (RDP, VNC, X11.) I remember Citrix thin terminals but I don't remember developers using them. They were for end users.
- regularfry 4y ago
  I've worked at a company where we used a shared server, relatively recently. Isolated environments were different /home directories and agreed port ranges. Actions that interfered with other folk were mistakes that happened once, because we were (for the most part) not a bunch of raging arseholes and were capable of talking to each other like adults. It was a lovely environment to work in, in part because sharing our work was a matter of "yeah, I've stood that up on port 6001, can you take a look?" Or "take a look at /home/foo/whatever.py, I think the bug's in there but I can't spot it". The other part was that it was an absolute beast of a machine for the time. RAM for days, and more cores than hot dinners. And, critically, a very close match to our production machines. That matters more than you'd think, for a large set of problems.
  - pramodbiligiri 4y ago
    This sounds fascinating. What was the config of that beastly dev machine, if you can tell?
gaocegege 4y ago
Remote development will be popular? Yes. But developing in a monolithic machine may be not. The development environment should be clean and isolated, and products like gitpod and coder is promising. Besides this, maybe you can have a look at https://github.com/tensorchord/envd https://github.com/tensorchord/envd and https://github.com/okteto/okteto https://github.com/okteto/okteto
swyx 4y ago
agree: I compiled a list of supporting facts and dissenting opinions here https://dx.tips/the-end-of-localhost https://dx.tips/the-end-of-localhost this is of course extremely hated on HN, which understandably loves independence and self reliance.
- crabmusket 4y ago
  Speaking as a person who does have a strong gut reaction against cloud development, I think a lot of the justifications like 'what if I'm on a train' do mask a real desire to say it just feels bad. Public reason. Is it logically consistent with other things I don't own? Like Chrome, within which all my apps run? No. But is there something that feels right about having all my code running on the CPU on my lap? Unaccountably, yes.
  - swyx 4y ago
    good for being intellectually honest about those justifications :) still, your feelings matter. imo, totally welcome to them. some people also like keeping gold in their safes, cash under their mattress, running on their own power and food off grid. i will fight for their right to do that. but also i observe that most people have a demonstrated tendency towards centralization for convenience, and the technology is coming along for mass availability of this tech.
- pksebben 4y ago
  there are more reasons that this take is bunkum than that article seems to be aware of. - security. the most common vector of attack is through dev boxes. centralizing creates a single point of failure. - vendor capture. right now, it's cheap to "do a dev". if you put everything in the cloud, the FAANG that be can start charging rent. - vscode or (insert cloud IDE here) might work great for some, but my local emacs is better. fight me. - the longer the distance between your devs and the metal, the dumber they get. you learn best by working with visibility into what your code is doing. many of the efficiencies mentioned will lead to educational drift, which is bad. - connection speed. he gets real hand wavy about "developing on a plane" but even developing on a satellite connection makes latency-dependant tasks super slow. try running Ansible from your star link and get back at me.
methyl 4y ago
How do you then work from a train for example?
PhilipTrauner 4y ago
I agree with the need for a standardized development setup (be it local or in the cloud) but violently disagree with eliminating development setup diversity. Curious engineers with oddball configurations greatly contribute to the overall health of a codebase. Forcing these folks to use a standardized configuration is a missed opportunity at best, and disgruntling at worst.
varispeed 4y ago
I used to work on remote servers, when the laptops were not powerful enough to sustain a full dev environment and at the same time renting dedicated servers wouldn't break a bank. Today, getting a server more performant than my laptop (M1 MB PRO) is not economically viable.
quickthrower2 4y ago
It is expensive though. Can get some nice local hardware for those cloud costs and then there is the latency. A cool option is give everyone the same laptop and set them up from a disk image. Keep data you want to keep on another partition. Reimage every so often with the latest required tooling. New starters will be thankful.
tasuki 4y ago
> some crazy interface that keeps their shell session alive even if their internet disconnects. This is a solved problem, see eg mosh. Not so crazy. But, I don't want my development environment running on the same box as other people's environments, it just doesn't make sense: people stepping on each other's toes, the whole box breaking... I really don't want that. Give me an environment that's possible to build from scratch with a push of a button, and I'll be happy. Anyway in a larger project there needs to be a person/team responsible for keeping the dev env up - either they can keep the shared one up with whatever black magic, or they can make sure the button to create the environment will work for people wherever and whenever they want.
mejutoco 4y ago
The only advantage I can think of in this scenario is monitoring of employees. As for disadvantages: - no work offline - no freedom for different OS, IDE, tools - Single Point of Failure (that server goes down, connection drops and nobody can do any work). IMO the cons are much worse than the pros. I am curious what other advantages you would see in this approach. EDIT: grammar, format
jen20 4y ago
I’m sat in a plane right now and am able to code with a high latency, low bandwidth internet link without issue. If I were using something from this dystopian vision of yours I’d not be able to do that. It doesn’t matter how much “courage” may be involved, frankly.

yencabulator 4y ago

Working in a remote forest is actually pretty pleasant. Offline matters.

trevor-e 4y ago

fwiw I know some FAANG companies (Google, Meta) have already transitioned to remote development machines that do exactly this.

politician 4y ago

Why is it a good thing to give up remote development for a centralized solution?

throwaway892238 4y ago
I dunno, man. Some "dev ops" jerk at work is always complaining about how he has to spend all his time answering support requests from developers with errors in their local environment. It only takes like a couple hours of my week, so what? And then when our deploys fail because the server didn't have the same version of python as our local environment, he tries to blame the fact that the local and remote environments are different! Can you believe the nerve of that guy? Keeps trying to convince us that a single centrally managed system is easier or more reliable (or whatever) than 30 randomly configured ones on multiple operating systems! I think he's nuts, personally. I have half a mind to tell my manager that he's trying to disrupt our ideal workflows. And really, what's the problem with testing my app in an environment that isn't the same as production? Yeah, sure, I might save some time not having to maintain a local environment that everyone on my team can replicate. And, sure, developing remotely would let me change laptops without spending a week to set everything up again; but it's only a week, I have a ton of those left. And yeah, maybe the cloud network has a bunch of services that I need proxies and VPNs and other things to test from my laptop. And granted, doing development on a server with 40 CPU cores and the same network as the database and webserver is faster than my laptop. ...But if all that was better, I'd be doing it already. If it's on my laptop, I know how it works. What's better than what you already know?
- politician 4y ago
  This is nonsense. We support a dozen developers running fully baked local development environments along with cloud-based dev, staging, and production environments. Multiple heterogeneous environments is normal. Granted, we don’t run any node, python or Ruby, because yeah I don’t want to spend all of my time debugging monkey patching bugs.
- maxbond 4y ago
  That sounds like a problem that can be solved with a CI/CD system and Docker Compose. Perhaps there is more going on here institutionally that stops this problem from being solved. It sounds like something really frustrating is going on though, and I hope it works out.
  - maxbond 4y ago
    Hey I'd like to expand on this a little bit. I hope I'm not presuming too much but as someone who recently had to leave their job due to burnout, I feel like I'm seeing signs of burnout here, and wanted to bring them to your attention. You sound really frustrated because you're being asked to do things that you feel aren't or shouldn't be part of your job, and perhaps it's taking time from your other responsibilities and creating a larger workload for you. It seems like maybe you've come to resent your coworkers and their individual preferences for the complexity it creates and the stress it causes you. It seems like what you want to do is erase that complexity, take away their agency, and centralize on a solution that works well for you. There's a couple of things to consider. For one, what you're asking is for your coworkers to have a degraded work experience so that your work experience can be better, which is totally understandable but not reasonable. Another one is that this is a pretty well understood problem with known solutions - why is it you can't get them implemented? Is there something going on in the politics or culture of your workplace that is stopping you? Is there some kind of elephant in the room, and would things get better if you called it out? The last one is, are you getting burned out? Were you always this frustrated? Should you take some time off? Should you start looking for other jobs? I can really feel the stress and frustration in your tone, and that sucks. I hope things get better for you.

minitech 4y ago

> Maybe in another 30 years, we will have gained the technological insight to be able to figure out how to have a team full of people to work on a single server at the same time Why is this desirable?

xvector 4y ago
Lightweight terminals with days of battery life while a juggernaut handles the real work.
- deleted 4y ago
  [deleted]
- legulere 4y ago
  But we already have notebooks with battery life for 2 work days which have very good performance like the M2 macbook air. And I highly doubt that it's the cpu that is the limiting factor for battery life and not the screen.
  - pksebben 4y ago
    not to mention, horsepower is hardly ever the choke these days. I would say that the greatest limiting factor here is the lack of screen space, because now your dev must context switch to read documentation etc

maxbond 4y ago

If that workflow works for you, that's awesome. As a lifelong Linux user who works primarily in the terminal and uses a terminal based editor, it would work for me too. Dismissing people who work differently as being cowards is a stance I hope you'll reconsider. Dictating to people how their workflow should look - _that_ is the antipattern. Developers should choose their OS, their editor, and virtually everything about their workflow. Forcing them to work remotely robs them of the opportunity - you can work graphically over SSH, and you can use SSH from Windows (if that is your preferred OS), but it's a hack that isn't always going to work quite right and is going to create unnecessary friction for people with different workflows than you or I. That's to say nothing of auxillary tools, like debuggers, that people may want to bring to bear. Don't get me started on getting debuggers to work over SSH, yes it can be done, yes I have done it, no I don't ever want to do it again. The infrastructure should bend to conform to the developer's needs, and not the other way around. Generally technology should conform to the needs of humans, and humans should not be asked to contort themselves for the benefits of technology. For instance, at my last company, I was asked to use a Mac laptop so that the team could standardize on Mac. I complied to be a team player, and this turned out to be a mistake. It robbed me of so much efficiency in the first few months, and it never worked as well for me as Debian running on my personal laptop, which cost a _third_ of the price of that Mac. I had so many frustrating issues and things that just never worked properly. But for other people, it was a great choice; I have no interest in bashing the Mac - my point is that people should be allowed to choose and customize their own tools.

fragmede 4y ago
> Dictating to people how their workflow should look - _that_ is the antipattern. Developers should choose their OS, their editor, and virtually everything about their workflow. I'm not convinced it is. Back in the day, each developer had their workstation (not laptop) configured just so, with their own pile of `doit.sh` scripts to tickle the system in just the right way, to get things to compile and render and send it off to production. But we're no longer there. Developer velocity is a thing companies take seriously, so developer workflow is actually important to them, and standardizing one true editor as the supported editor means that all the developers get improvements whenever the internal tooling team does a release. And I'm saying this as a vim person who's tried to move over to VSCode (and have failed so far). Of course, smaller companies don't have an internal tooling or developer productivity team, and thus allowing people to choose their own tools is optimal. But I've also seen the big picture efficiency loss that results from every developer having a bespoke configuration thats intelligible only to themselves, and the inability to unilaterally improve people's tooling and integrations with various systems they interact with. Once the team gets debugging over SSH working or whatever, they can just deploy that, in a working state, to everyone. There's a world where Slack is the one true communication method and everyone is on a Macs. Unfortunately for me I'm set in my ways would rather use Ubuntu on a Thinkpad with vim, but that doesn't mean I haven't see that other world.

gitgud 4y ago

> Maybe in another 30 years, we will have gained the technological insight to be able to figure out how to have a team full of people to work on a single server at the same time Single repository, yes. Single development environment, no. Development environments should be isolated, so developers don't step on each other's toes... Also, centralised cloud development machines are by definition, a single point of failure, with small gains in consistency in development experience... > all connected to a network over an internet connection, with some crazy interface that keeps their shell session alive even if their internet disconnects. You know what's better than this? Not relying on the internet connection at all!... Decentralized development on local machines is simply a better experience and relies less on a giant cloud infrastructure

quickthrower2 4y ago
And tools like the one that spawned this HN discussion are going to help homogenise things and make it easier to go local.

denkmoon 4y ago

I've certainly had internet outages where I've continued to work on my laptop. I can't even imagine how expensive it would be to run like this. Sharing an environment is a _terrible_ idea, you need isolated environments.

bigtunacan 4y ago

It's unpopular because it's a terrible idea. Just because it's easy ssh'ing into the box, doesn't mean you should. Twenty years ago we didn't have the tools to do anything better. And while I miss some of the simplicity of those times I don't miss when someone ssh'ed into the server and fucked something up and left us in a lurch. If you really think this is the best approach today I really hope you aren't working on any critical systems.

ithrow 4y ago
It's for dev systems not production.

pmontra 4y ago

That is how I and everybody else were developing software at my university around 1990. A few HP servers, character terminals or X11 servers. Then everybody got a Windows desktop at home powerful enough to work as on those X servers and it was game over. I never saw a company developing on a shared server. Do you work for one doing that? In that environment I expect developers to need separate environments not to stop all the team in case of mistakes. Let's say: docker containers running on the server instead of pulling an image locally. I don't see much of a gain. Personally I could use my emacs to edit files of the server, my terminal to ssh on the server and my browser getting pages from there. For people using IDEs, those IDEs should either work in a different way or be in a remote connection (RDP, VNC, X11.) I remember Citrix thin terminals but I don't remember developers using them. They were for end users.

regularfry 4y ago
I've worked at a company where we used a shared server, relatively recently. Isolated environments were different /home directories and agreed port ranges. Actions that interfered with other folk were mistakes that happened once, because we were (for the most part) not a bunch of raging arseholes and were capable of talking to each other like adults. It was a lovely environment to work in, in part because sharing our work was a matter of "yeah, I've stood that up on port 6001, can you take a look?" Or "take a look at /home/foo/whatever.py, I think the bug's in there but I can't spot it". The other part was that it was an absolute beast of a machine for the time. RAM for days, and more cores than hot dinners. And, critically, a very close match to our production machines. That matters more than you'd think, for a large set of problems.
- pramodbiligiri 4y ago
  This sounds fascinating. What was the config of that beastly dev machine, if you can tell?

gaocegege 4y ago

Remote development will be popular? Yes. But developing in a monolithic machine may be not. The development environment should be clean and isolated, and products like gitpod and coder is promising. Besides this, maybe you can have a look at https://github.com/tensorchord/envd https://github.com/tensorchord/envd and https://github.com/okteto/okteto https://github.com/okteto/okteto

swyx 4y ago

agree: I compiled a list of supporting facts and dissenting opinions here https://dx.tips/the-end-of-localhost https://dx.tips/the-end-of-localhost this is of course extremely hated on HN, which understandably loves independence and self reliance.

crabmusket 4y ago
Speaking as a person who does have a strong gut reaction against cloud development, I think a lot of the justifications like 'what if I'm on a train' do mask a real desire to say it just feels bad. Public reason. Is it logically consistent with other things I don't own? Like Chrome, within which all my apps run? No. But is there something that feels right about having all my code running on the CPU on my lap? Unaccountably, yes.
- swyx 4y ago
  good for being intellectually honest about those justifications :) still, your feelings matter. imo, totally welcome to them. some people also like keeping gold in their safes, cash under their mattress, running on their own power and food off grid. i will fight for their right to do that. but also i observe that most people have a demonstrated tendency towards centralization for convenience, and the technology is coming along for mass availability of this tech.
pksebben 4y ago
there are more reasons that this take is bunkum than that article seems to be aware of. - security. the most common vector of attack is through dev boxes. centralizing creates a single point of failure. - vendor capture. right now, it's cheap to "do a dev". if you put everything in the cloud, the FAANG that be can start charging rent. - vscode or (insert cloud IDE here) might work great for some, but my local emacs is better. fight me. - the longer the distance between your devs and the metal, the dumber they get. you learn best by working with visibility into what your code is doing. many of the efficiencies mentioned will lead to educational drift, which is bad. - connection speed. he gets real hand wavy about "developing on a plane" but even developing on a satellite connection makes latency-dependant tasks super slow. try running Ansible from your star link and get back at me.

methyl 4y ago

How do you then work from a train for example?

PhilipTrauner 4y ago

I agree with the need for a standardized development setup (be it local or in the cloud) but violently disagree with eliminating development setup diversity. Curious engineers with oddball configurations greatly contribute to the overall health of a codebase. Forcing these folks to use a standardized configuration is a missed opportunity at best, and disgruntling at worst.

varispeed 4y ago

I used to work on remote servers, when the laptops were not powerful enough to sustain a full dev environment and at the same time renting dedicated servers wouldn't break a bank. Today, getting a server more performant than my laptop (M1 MB PRO) is not economically viable.

quickthrower2 4y ago

It is expensive though. Can get some nice local hardware for those cloud costs and then there is the latency. A cool option is give everyone the same laptop and set them up from a disk image. Keep data you want to keep on another partition. Reimage every so often with the latest required tooling. New starters will be thankful.

tasuki 4y ago

> some crazy interface that keeps their shell session alive even if their internet disconnects. This is a solved problem, see eg mosh. Not so crazy. But, I don't want my development environment running on the same box as other people's environments, it just doesn't make sense: people stepping on each other's toes, the whole box breaking... I really don't want that. Give me an environment that's possible to build from scratch with a push of a button, and I'll be happy. Anyway in a larger project there needs to be a person/team responsible for keeping the dev env up - either they can keep the shared one up with whatever black magic, or they can make sure the button to create the environment will work for people wherever and whenever they want.

mejutoco 4y ago

The only advantage I can think of in this scenario is monitoring of employees. As for disadvantages: - no work offline - no freedom for different OS, IDE, tools - Single Point of Failure (that server goes down, connection drops and nobody can do any work). IMO the cons are much worse than the pros. I am curious what other advantages you would see in this approach. EDIT: grammar, format

jen20 4y ago

I’m sat in a plane right now and am able to code with a high latency, low bandwidth internet link without issue. If I were using something from this dystopian vision of yours I’d not be able to do that. It doesn’t matter how much “courage” may be involved, frankly.