4 ms·

My opinion is that every team member should have the same editor with the same settings. The settings should be easily accessible from Confluence or a similar k

My opinion is that every team member should have the same editor with the same settings. The settings should be easily accessible from Confluence or a similar knowledge base.

iopuy 8y ago
Agreed, it should be part of the standard technical on-boarding process. Once someone is familiar with what the editor is buying them in terms of productivity they are free to search for their own should they choose. A pet peeve of mine is joining a new team and asking what the editor of choice is to be told "really it is up to you."
PurplePanda 8y ago
what's the point of that? it takes a while to learn how to use your text editor well, and everyone is probably good at a different one. but they all pretty well have the ability to produce the same result, so why bother forcing one? it's better to (have a tool that can) specify what the end result should look like and let people work the way that they are good at.
- cimmanom 8y ago
  Agreed. Plus now many editors obey the same .editorconfig files; and for those that don't, .editorconfig can be used as a reference for developers to configure their own working environment. I can understand wanting to standardize in a company with a 1000-person engineering org, where maybe it's harder to enforce that everyone uses the same conventions if there's no standardization in tools; but in a team of a few dozen, you should only be hiring people you trust anyway, and communicating with them about why small things like this are important.
- systemtest 8y ago
  In my team everyone uses IntelliJ Ultimate with the same settings.xml file. We all have the same automatic tasks that happen on each commit: reformat code, optimize imports, check TODOs, perform SonarLint analysis. This has greatly reduced frustrated merge-requests filled with unimportant details such as code formatting and newlines. It has also greatly improved the code quality because it will warn you that you left a TODO in the code or that a certain method could also be private before you commit the code into the repo. Nobody has a problem with this, although in the Java world every corporate developer uses IntelliJ anyway. A couple of legacy project teams are still on Eclipse.
sakarisson 8y ago
As long as everyone has the same linters, what does it matter what editors they use?
tasuki 8y ago
I can see why everyone should use the same settings, but am not sure why everyone should use the same editor. An easy way to sync formatting: https://editorconfig.org/ https://editorconfig.org/
adtac 8y ago
This will pretty much guarantee a decrease in productivity, as opposed to the original intention to increase productivity. Why can't everyone use their own editor? Enforce standards, not tools. Something like editorconfig (I use it in pretty much every large project I have) solves this for you.
klibertp 8y ago
That's going to improve the overall productivity of the worst (maybe) devs while hurting the productivity of the best ones. For the latter, it took years to get to the level of proficiency they are on now with their editor, and they are not going to be as productive in the new one for a long time[1]. You're intentionally crippling them by taking their tool away - why would you do this? Why do you expect they'll put up with it? [1] And that's assuming your chosen editor is objectively comparable in features with the one they used, which it probably isn't unless it's the one extensible in Lisp ;)
- deleted 8y ago
  [deleted]
deleted 8y ago
[deleted]
twic 8y ago
If you're pair programming, you should absolutely do this. It's a substantial impediment to equal contribution if you don't. If you're not pairing, it seems like a move with a poor payoff for its cost. Sure, make sure everyone has identical code style in their auto-formatter, but let them pick their own editor.

My opinion is that every team member should have the same editor with the same settings. The settings should be easily accessible from Confluence or a similar knowledge base.

iopuy 8y ago

Agreed, it should be part of the standard technical on-boarding process. Once someone is familiar with what the editor is buying them in terms of productivity they are free to search for their own should they choose. A pet peeve of mine is joining a new team and asking what the editor of choice is to be told "really it is up to you."

PurplePanda 8y ago

what's the point of that? it takes a while to learn how to use your text editor well, and everyone is probably good at a different one. but they all pretty well have the ability to produce the same result, so why bother forcing one? it's better to (have a tool that can) specify what the end result should look like and let people work the way that they are good at.

cimmanom 8y ago
Agreed. Plus now many editors obey the same .editorconfig files; and for those that don't, .editorconfig can be used as a reference for developers to configure their own working environment. I can understand wanting to standardize in a company with a 1000-person engineering org, where maybe it's harder to enforce that everyone uses the same conventions if there's no standardization in tools; but in a team of a few dozen, you should only be hiring people you trust anyway, and communicating with them about why small things like this are important.
systemtest 8y ago
In my team everyone uses IntelliJ Ultimate with the same settings.xml file. We all have the same automatic tasks that happen on each commit: reformat code, optimize imports, check TODOs, perform SonarLint analysis. This has greatly reduced frustrated merge-requests filled with unimportant details such as code formatting and newlines. It has also greatly improved the code quality because it will warn you that you left a TODO in the code or that a certain method could also be private before you commit the code into the repo. Nobody has a problem with this, although in the Java world every corporate developer uses IntelliJ anyway. A couple of legacy project teams are still on Eclipse.

sakarisson 8y ago

As long as everyone has the same linters, what does it matter what editors they use?

tasuki 8y ago

I can see why everyone should use the same settings, but am not sure why everyone should use the same editor. An easy way to sync formatting: https://editorconfig.org/ https://editorconfig.org/

adtac 8y ago

This will pretty much guarantee a decrease in productivity, as opposed to the original intention to increase productivity. Why can't everyone use their own editor? Enforce standards, not tools. Something like editorconfig (I use it in pretty much every large project I have) solves this for you.

klibertp 8y ago

That's going to improve the overall productivity of the worst (maybe) devs while hurting the productivity of the best ones. For the latter, it took years to get to the level of proficiency they are on now with their editor, and they are not going to be as productive in the new one for a long time[1]. You're intentionally crippling them by taking their tool away - why would you do this? Why do you expect they'll put up with it? [1] And that's assuming your chosen editor is objectively comparable in features with the one they used, which it probably isn't unless it's the one extensible in Lisp ;)

deleted 8y ago
[deleted]

deleted 8y ago

[deleted]

twic 8y ago

If you're pair programming, you should absolutely do this. It's a substantial impediment to equal contribution if you don't. If you're not pairing, it seems like a move with a poor payoff for its cost. Sure, make sure everyone has identical code style in their auto-formatter, but let them pick their own editor.