This is ignoring the removal of control from your developers. Autonomy of tool choice is an amazing boon to job satisfaction.
Which is not to say that a cloud environment should not be used. Just don't homogenize the setup.
> This is ignoring the removal of control from your developers. Autonomy of tool choice is an amazing boon to job satisfaction.
> Which is not to say that a cloud environment should not be used. Just don't homogenize the setup.
IMO, there is a good middle ground.
I agree with you on stuff like editor/ide and base OS. But I think there can be great advantages to having everyone do development in docker/VM such that the environment matches prod.
In particular, I think local deployment is important. And having freedom in all local deploys leads to finding the small details that matter.
Especially since you probably do not own the full prod tech stack, you are behooved by having proof that you can change it.
And, by all means, make the best attempt you can. I am arguing that somewhat purposely breaking it in a regular basis with each new developer makes you more resilient if you have to do a change in prod someday. And you will, someday.
There is a hidden issue with not standardizing. Most people either don't care about local vs container (matching prod) development OR are terrible not equipped to make an informed choice. Thus, as a devops, I have to support both methods. This is a huge drain on my resources, especially since devopsing is just part of what I need to do.
The root cause of this is the myth that all software engineers will understand source control, will understand databases, will understand how systems interact with each other and on top of it, will understand the business so they can actually do the work required. This is how you end up with "it works on my machine". This is how you end up with "but it works in repl, therefore your prod environment is broken".
Standardizing doesn't mean this is the only way of doing things. It means, this is the standard way of doing things and if you get stuck, you get support. It means this is the way we consider to be most efficient of doing this stuff. You are still free to do things your way if you chose to, but if you get stuck, it's on you to get unstuck.
And agreed that conforming to what others are doing will, by definition, get you more support. I just think there is hidden value in that diversity. It sucks, as it can't be forced/codified.
I will further agree that too many will chase the "long game" of "if we support diverse environments, we will have a more robust product," at the expense of short term health. And often that is a false dichotomy, in that often the best long term choice for a team is also the best short term tradeoff. Surviving is important.
Containerised workspaces can be version controlled, which gives you the flexibility to fork a copy mess around but still go back to a known good state. And the new branch can easily be cloned for others to use.
Cloud dev environments are a tool like any other. How they're designed matters. A lot of home grown tooling ends up being limited for ease of build out and maintenance cost/effort.
This is a public company and I have compliance requirements to meet or I am personally liable or face jail time. And with thousands/tens-of-thousands of engineers, your tool choice and lack of streamlined repeatable systems is costing us millions of dollars in profits every year and keeping your pay and the value of your equity down.
If you're going to depend on collectivist systems to provide you a stable livelihood, don't be surprised that the collective doesn't reward your individuality and entreprenureal spirit. There are other organizations that value that. Go work for them.
It sounds like you think that because you can't measure it, you are legally obligated to assert that it is zero.
You are bad at your job.
As a matter of fact, many listed companies reward an entrepreneurial spirit and value employee satisfaction, because that’s usually linked to sustainable growth.
I would also say that dev environments can be “streamlined” and “repeatable” while allowing for personal choice of editor and whatever other ancillary tools the developer is productive with. They’re not mutually exclusive.
My observation has been that teams that don't have tool choice almost always lost it because they had an overly specified build environment. Often under the guise of "streamlining" the setup. And this is why they have that particular build server still sitting around that only the head developer is allowed to modify.
In what should be a straw man argument, I've seen this go so far as folks not knowing how to even try to build their software on anything other than the sanctioned IDE with them having to use the mouse to click the "now build" button.
Which is all to say, my argument is intended to be that you do need a repeatable and streamlined build system that is tested and run in a variety of environments. The more diversity in where/how it is run, the more trust I have that the team actually understands how it works. Especially as a whole.
For the personal control, letting the devs accomplish onboarding in a way that they control empowers them to make the changes to the setup that help make that happen, and gives more autonomy to them. Giving them autonomy means they can fix things they see. And you want that, as they will see far far more of what is happening than board level management will.
Does this mean you can't/don't meet compliance? Of course not. Most compliance can be tested. And it should be tested. Again, this testing benefits from diversity of execution, as well, such that a test that can pass on a variety of environments and toolsets is far more trustworthy than one that can only pass on a particularly sanctioned setup.
Now, pulling this back from a straw man argument. I accept there are situations where this level of freedom is harder to achieve. If you take my argument as absolute requiring that the entire team supports every possible variation of tool that could be thrown at them, please walk it back some. That isn't my intent. I just get scared by efforts to unify it all down to one, as well.