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...
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.
> 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.
Have you tried neovim? You can have pretty close to feature parity with VSCode due to it's LSP support; for most languages, you'll be using the exact same Intellisense engine (LSP server) as VSCode. (Python is the exception I'm aware of, but python-lsp-server is serviceable even if Pylance, the proprietary VSCode one, is better). And when the internal tooling team ships a new version of the LSP server, you'll be able to use it too!
When it comes to everyone building things the same way - that's what containers and CI/CD is for. If we didn't have those tools, then I may be more inclined to agree, but we do and they work. Do they work perfectly? No. But they ought to surpass this fairly low bar. If they didn't then I don't see how we'd have confidence in a centralized solution either.
I literally cannot use an editor other than neovim without hurting myself due to an RSI problem. Believe me, I have tried them all. If I was told that I must adopt VSCode, I would literally have to quit for my health. That being said, VSCode is an excellent tool, and some people I know with RSI issues swear by it. More power to them.
Developer velocity is definitely not going to be helped by handicapping your developers and forcing them to use tools that don't quite fit their workflow. I'm reminded of an anecdote about fighter pilots, it may be apocryphal, I don't know. But it goes like this; the air force was designing the seat for their fighter planes. So they took measurements of a statistically significant number of fighter pilots (all or most of whom were men), averaged them, and designed a seat to accommodate that figure. But pilots complained the seats were uncomfortable, and as the demographics changed and more women became fighter pilots, they were very poorly served by the chairs. Eventually they realized that they had designed the seat for a body that no one had. So when they redesigned it, they designed a seat which was customizable, and allowed each pilot to get a seat which was comfortable for them.
Anointing a "one true workflow" is a similar mistake. It will chaff at your developers and you'll lose velocity due to the chaffing. Over time requirements will change and the workflow will cease to meet anyone's needs, and if your developers remain productive it will be because they are going behind your back to use what actually works for them. Your developers will leave you because they're tired of being patronized, and you'll lose velocity and institutional knowledge onboarding new people.
The internal tooling team can't be all things to all developers, that's true. Let them ship what they ship, and let other people figure out how to adapt it into their workflows. If someone is performing well and getting stuff done, do you care if they're using the internal tools? Or if they've wrapped the internal tool in some macros or something to better suit them? If someone is using the anointed workflow but can't work for more than an hour at once because it's too mouse heavy and it hurts their wrist, is anyone in the situation happy?
> 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
> 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
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.
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
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.
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.
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?
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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...