Hacker News new | past | comments | ask | show | jobs | submit login

Call me a despot, but I am of the opinion that everyone should use the same development environment in a given team. That means same editor, same style and same OS. People might complain in the beginning if they have to change from another environment, but that will be short-lived, and the cost will be minimal compared to the otherwise continuing wankery and bickering over each developer’s subjective opinions on code style and editor. Why? The manager says so. It’s so simple at that point.

I couldn't disagree more. With modern tools like gofmt and Prettier for code formatting and Vagrant for dev VMs, it basically doesn't matter what environment anyone works in. Code style should always be enforced in an automated way, and running all your software in a VM means you don't need to install anything locally except for an editor and Git.

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.

You underestimate the value of uniformity and group pressure. Everyone gets used to the one environment in the end. 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.

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.

> You underestimate the value of uniformity and group pressure.

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".

> IME, it takes several months to really become fluent and productive in a new editor

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.

I've tried many editors for various reasons, although I've never been forced to learn a new one for work. (The time I worked at a place where everyone used the same editor, it happened to be IntelliJ, with which I was already familiar.) The most difficult was when I switched to Vim fulltime to learn it. It took me about a year to really "grok" it and become productive. I've also done the same with Atom and VS Code, but those never felt as productive for me, so I gave up a month or two in. I keep coming back to IntelliJ, which is what I use now, because it fits so well with the way I work and I'm most productive with it.

Docker, Vagrant, build tools are all the same. They should just be uniform. Don't hire someone unexperienced in the uniform language. After that, one-time investment in assimilation to the uniform environment. That versus never-ending loss.

I completely agree with all of that, but I don't see what that has to do with your choice of editor or OS. If you use Vagrant/Docker, all your build tools should live there, so it doesn't matter what OS you use. I don't see what "never-ending loss" you face when people use different OSes or editors; I've never faced that in practice as it literally doesn't matter.

You’ve moved the OS into the docker image, so it’s basically the same OS, therefore I’m satisfied. What runs the docker image is less important, but it would be better to have uniform computers and OS in case one of them breaks. You can replace it much more easily.

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 grossly underestimate our industry's ability to wank and bicker over everything anyway.

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.

Hyper-standardized, pants-shittingly brittle build environments stemming from the mentality that the OP is suggesting is its own special sort of hell. It's "works on my machine" applied to a way bigger surface.

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.

How did it bite you in the ass out of honest interest? I have not done commercial C++, so I would be interested to know.

We were hit with the reality that the software (and/or components of it) may need to be run on Linux, OSX, and other targets at some point in the near future. At the time, everything was done with a single IDE, a single compiler, with specific old versions of libraries, only targeting Windows, and with no expectation that it would ever have to be done any other way, even though we probably should have assumed that the day would come. It was always assumed that it would just work, but life comes at you fast when you actually have to do it. After weaning the project off of environment specific tools, the process has become a lot more like our initial assumption.

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.

Thanks for the input. Couldn’t that be solved by automated building and testing over multiple VMs?

Most anything can be solved by automation in software. The trick here is the anti-fragile nature of every new team member being a slight shock to the system.

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.

I never understand how people can even argue that uniform style is necessary, you have to dig into 3rd party code with different styles every day anyway.

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.

git diff -C can show rearrangements and renames.

it still pollutes the git blame, doesn't help with web views of code repos and causes more merge/rebase conflicts.

the sorting causes more problems than its very questionable worth.

Setting the git diff algorithm to patience or histogram would probably solve a lot of the merge issues. You’re right on the web views. It would be nice if they respected the algorithm setting from the git config.

In my experience the diff algorithms do nothing when one person moves the function and another edits it. The algos just fiddle around the margins of diff hunks.

> If people are using different environments, people are still able to wank and bicker over differences in environment.

How far would you take it? Would you (like Steve Jobs) try to get everyone to dress the same, too?

There’s a reason behind uniform in many institutions.

Interesting use of the passive voice! Yes, there is. Also common in places with uniforms: requirements for haircuts, nails, makeup/perfumes, daily inspections, etc. You didn't answer my question.

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.

Wikipedia does not say that the above is an example of the passive voice. Passive voice requires past participle. "is" above is present continuous anyway.

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.

> Interesting use of the passive voice!

http://www.lel.ed.ac.uk/~gpullum/passive_loathing.pdf esp 3 (25)

Or they just leave.

I would strongly consider leaving if my manager decreed that I mustn’t use vim and must instead use webstorm/atom/whatever (especially if not in vim mode).

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 have decades of experience with my preferred editor. That has more value than your whitespace preferences, even if they were incompatible (which isn't true).

I have used Emacs for over half my life. I had to use IntelliJ. Coding style was enforced. Same OS. It was fine. Maybe a bit of a struggle in the beginning. It was actually brilliant. I was soon whizzing away having learnt all the new shortcuts.

I would choose the benefit of uniformity over my personal preferences any day. You don’t know until you’ve seen it.

IntelliJ shortcuts are easy to learn because it hardly has any, in comparison. It's decent at Java boilerplate, but have you started writing plugins for editing other files? Because I can't convince myself that's worth the time investment.

If there aren't easily available and widely used tools for a chosen language, then it might not be the right choice.

Or the manager could just get everyone to stop their "continuing wankery and bickering over each developer’s subjective opinions". If you're a professional, you should act like 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.

I don’t agree with the analogy. The interface of a drill is much less complex and is basically the same over all brands. The longevity and power may well differ. Drill bits are standard and work as well in a Makita as in a DeWalt. I don’t think that tradesmen personally identify with their drills. Drills are not political.

Thus, EditorConfig! It's a standard for editor configuration, and is basically the same in all text editors.

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.

Developers are not unique in thinking that they are unique.

I agree with you if that editor is Emacs and the OS is Linux.

Don't you mean that OS is Emacs and the editor is evil... :)

> Linux

Linux is not a OS, it's a kernel. You would also have to force all developers onto the same distribution.

Yes, Gentoo.

is Emacs as OS on top of the Linux kernel a GNU/Linux?

I agree with you, but I am not the manager.

Beat me to it! LOL

This works, for some value of working, in structured corporate teams but good luck forcing open source developers to use a specific editor per project.

Have you actually tried this, and how did it work out on the team?

Yes. I hated it in the beginning, but it was so nice later on to be able to work together, share tools, share build scripts, to know my stuff would work on their stuff and to concentrate on the real issues.

Can you explain the situation and original environment a little more?

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 don't know what led to the decision. The CEO had already built a very successful company on the same principles. The company where I worked had these same principles from day one. This also happened to be a start-up and not a megacorp. This was not in an anglophone country, so norms differ. I am from England for the record. Out of all of the companies where I have worked, this has been the most successful, and became successful the quickest. The IDE was IntelliJ-based.

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.

I'd leave any company where they tried to enforce that. Thankfully I'm at a career point where I get to decide without leaving, but I still regularly tell recruiters I'm not interested on the basis of OS and platform choices. It matters that much to my happiness.

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.

I respect your preference. I now prefer the tranquility of assimilation and consistency in my career. I would also tell recruiters that I do not care about OS and platform choices, as long as they are uniform across unique teams.

That's why I love languages with formatting tools like gofmt. There's no arguing about style, you just set it to format your code on each save.

Maybe not force everyone to use the same environment although it have tradeoffs. But absolutely lock down versions of tools used. I've had lost commits because different versions of SCM was used. Or stuff not working in different version of framework.

But why? You can enforce coding styles in a passive way through linters and formateers that work actoss IDEs. And in those rare cases that a junior dev is trying to show their worth by using a poorly configured VIM or Emacs, then there’s pre-commit hooks.

> That means same editor, same style and same OS.

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.

Multiple build targets enforced uniformly over the whole team.

I'm not talking about build issues, but runtime ones. There's a lot of stuff that comes up during routine debugging of desktop apps, for example.

There should be a process in place for routine testing on each target environment. Testing on BeOS shouldn't just be done because Bob happens to like doing his development on BeOS.

I didn't say that was the only testing, either. However, use during development is also testing, and in practice it can easily add up to more hours of testing than routine testing - and if all of those hours are on the same platform, then you get skewed picture overall. In addition, routine testing is usually much more scripted.

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?

Good luck making the UI developers use the same tools as the autonomy and perception engineers.

See “team”.

Not everyone works as developer #4932 on some fungible homogenous team.

That's it, isn't it? I cannot think of any other profession where such a large majority of people defend so strongly their right to work on their own terms inside an organisation. When was the last time you heard about a solicitor or someone from HR complaining that he won't use Excel or Word because org-mode or Corel Wordperfect is better for his needs, and he can just email the .org files around anyway. People can open them with wordpad.exe or TextEdit if they like.

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.

I hate to say it but after reading all of your comments this on in particular think I'm sold on the idea and I was really against it when I read your first comment. I don't know if will catch on but I would definitely give it a chance.

Interesting thoughts. I haven't given it that much thought. All I know is that the tools that are great for C++ development aren't equally as great for web application development. But we are all certainly on the same team, collaborating on a daily basis.

It felt absurd that if we aren't all doing the same job then surely we're not on the same team

You're right on that. I never viewed backend and frontend as the same team. Obviously they should be using the appropriate tools for their job.

> Why? The manager says so.

That attitude is the quickest way to lose my respect.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact