Edit: Obviously this doesn't apply if you do platform-specific work (like iOS development) or rely on tools that are only available on a single platform; in that case, you're probably right.
If people are using different environments, people are still able to wank and bicker over differences in environment.
By the way, it’s not just about code style and editor. By sharing the same environment, people can share build tools and other tools much more easily.
I don't, because I've worked in both kinds of environments and have not seen any benefits to the system you propose. Uniform development machines doesn't automatically mean that you've solved all consistency problems. Also, I'm not sure what you mean by "build tools" specifically, but any software needed for a project to run should ideally live within a Vagrant VM (or Docker or whatever), so it should be self-contained and not require any installation of additional software.
> How did you pick up a programming language and editor in the first place? How did you pick up a new one? It was fine.
IME, it takes several months to really become fluent and productive in a new editor, and potentially longer for a new language (depending on previous experience, etc). So "it's fine" as long as you consider a multi-month learning curve "fine".
I'm interested to know what editors you have switched to/from and why. Example, switched from emacs to vi because manager forced us to, etc.
What remains is editor/IDE. I’m still of the opinion that everyone should use the same development environment, preferably a full-fledged IDE which enforces code style at write time. This also prevents the bad diff issue, amongst a lot of the more important problems I’ve explained elsewhere.
Of course it’s all a matter of opinion. I base this opinion on how I experienced this environment. Nowhere else I’ve worked managed to get so much done and collaborate so easily.
You also overvalue uniformity. Or under value the antifragility of not caring how the code was created. The most fragile systems I have ever had the displeasure of being near, required a very specific build machine because the environment couldn't be replicated. In large, because the original development team did what you propose, and mandated all development happen using the same controlled environment.
Yes, a team obviously has to agree on obvious things such as language and build system. However, cornering yourself into such a tight environment leaves a lot of opportunities to have the rug get pulled out from under you.
I currently work on a team that writes DAQ software in C++ for Windows. The developer has their choice in everything (editor, VCS front-end, debugging and profiling, etc.) as long as the build system runs, their code meets the team's code standards, and they're productive with it. We've found that we can basically close our eyes, point at a random target system, and odds are that our code base can be trivially ported to that target with minimal effort. That reality is possible because somebody has incidentally tested just about everything. At one point in the past, we had a pretty narrow/rigid build process, and it bit us in the ass and hamstrung more developers than it was worth.
C/C++ are unique in that build processes and integrating other people's code in them are inordinately hard problems in and of themselves. Different compilers will behave a little differently, different operating systems will behave a little differently, and some of the niceties that a certain IDE or tool provide you will behave a little differently, depending on the exact circumstances you're dealing with. The safe thing to do is make no environment assumptions, and try to make everything as portable between environments as possible. You need to have your focuses, but it's reassuring to know that you can jump ship if and when you need to.
You still need solid testing for making sure you don't miss regressions. So, we aren't claiming this is a replacement for any solid engineering strategies.
And imo autoformatters are too inflexible. Most default rules are ok when you don't make any effort about formatting at all but break down when you manually lay out things for improved readibility. E.g. when splitting arguments to one arg per line and parens on separate lines and the autoformatter will just go and squash them all together into single lines up to the line limit, except the lambda in the middle which will be broken out into a separate line. Or other fun things like that.
Formatters which rearrange code by alphabetical sorting or sorting by visibility are even worse. They can introduce so much commit noise just because you change an identifier.
the sorting causes more problems than its very questionable worth.
How far would you take it? Would you (like Steve Jobs) try to get everyone to dress the same, too?
As Wikipedia says: "Modern uniforms are most often worn by armed forces and paramilitary organizations such as police, emergency services, security guards, in some workplaces and schools and by inmates in prisons."
One of these things is not like the others. Is running your professional software team like a paramilitary group or prison the only way you can get them to stop "bickering"? For people who are immature enough to bicker about any difference between individuals, when you enforce the standardization of one attribute, they just switch to something else.
I don't think that running a software team like a paramilitary group is the only way to stop bickering, but some elements of how paramilitary groups are managed are very attractive in this context, and seem to have worked where I saw them applied.
The employees of a lot of banks happen to wear suits, shirts and trousers, programmers included. I wouldn't discount the benefit of this purely because paramilitary organisations also happen to enforce a uniform.
http://www.lel.ed.ac.uk/~gpullum/passive_loathing.pdf esp 3 (25)
I’ve spent a lot of time setting up my dev environment so it works well for me, and I’m more productive and happy in it.
Style/formatting consistency is one thing, but editor uniformity is an unrelated thing. Yes, it makes collaborating easier, but is that worth the cost of people being less happy or less productive?
I don’t dislike other editors, but I like my setup a lot, and there are, imo, pretty huge switching costs involved in switching to/from vim/emacs and a GUI editor.
I would choose the benefit of uniformity over my personal preferences any day. You don’t know until you’ve seen it.
Most of my friends and coworkers use DeWalt, while some use Milwaukee, and there's even a few oddballs who use Makita, but I've never heard any 'bickering' about it.
Drill bits are standard, but lots of other tool interfaces are not. Batteries are not at all compatible, for example, and not even within the same brand (different voltage, different battery chemistry, ...). When someone's Milwaukee 18V lithium battery dies, and there's only a DeWalt 20V charger, nobody makes snide remarks about brand, any more than if you had the wrong size wrench for the bolt you needed to tighten.
It's true that "drills are not political", so why would you allow developers to claim that text editors are? That is a social problem, so it requires a social solution. You seem to keep implying that software developers uniquely posses an inability to behave reasonably in the presence of alternatives.
Linux is not a OS, it's a kernel. You would also have to force all developers onto the same distribution.
Those haven't been problems for the teams I've been on, and we've always been "every man for himself" when it comes to dev environment. As long as code follows the style guide, passes tests and gets through a code review, nobody cares about the dev's environment. Did you try that and it didn't work? What led to management mandating conformity?
I have never before or since worked at a company that allowed "every man for himself" while managing to enforce the discipline required to maintain a uniform style guide, tests always passing and code review. It was nice to go over to a colleague's computer and see exactly the same code as I see on my own, and in the same environment. Everyone used the same debugger interface and same unit test interface, because everyone used the same IDE. They become more natural to use. People were able to refactor easily and maintain consistent naming standards, which is more difficult in Emacs, and especially in vim.
So yes, the objections will be shortlived because anyone good enough to have options that don't like your choices will choose not to work in your team.
The OS used for development is, in many cases, also the OS used for routine debugging. An OS monoculture on a cross-platform product team means that some product gets a lot more incidental testing than the others.
But frankly, your original point doesn't make sense to me, because there's simply no downside, so why argue about upsides? The team can agree on a single code style (or have that mandated from above), but how does that affect editors, and especially OSes? The only meaningful constraint is that one's choices must be able to handle the mandated style.
Same thing for other stuff. For example, it makes sense to mandate a testing framework. But if multiple IDEs support that framework, what's the point of forcing the choice on that?
I wonder whether this is actually a sort of class issue. The dissonance between being part of god's chosen tribe and the realisation of being decidedly middle class all the while. It manifests itself by turning people into Emacs emos. It's not a phase, I am unique, and I'll run away from home if you tell me otherwise.
It felt absurd that if we aren't all doing the same job then surely we're not on the same team
That attitude is the quickest way to lose my respect.