4 ms·

None of this matters in the slightest as soon as you have to work with other people on stuff. At that point common tooling is more important than specific perso

None of this matters in the slightest as soon as you have to work with other people on stuff. At that point common tooling is more important than specific personalised tooling. If everyone is using IntelliJ and you're using Atom, it's going to be problematic. Not because of either of those tools, but because you now have a discrepancy that is not relevant to the work you're doing yet it's creating problems for the work you're doing. Adding friction like that doesn't help anyone. "Works on my machine" doesn't just apply to the artifacts you build, it also applies to the way you work on your project. Of course there is some difference between multiple people editing random plain text in a random editor and multiple people building a piece of software with a toolchain, deployment strategy, tests etc. If everyone in your team can scaffold the tests in 1 second because that's what the IDE does, and you're the only one that has to burn half a day on manually stubbing out the same scaffolding, you're the problem.

deleted 5y ago
[deleted]
Lio 5y ago
I don’t quite get this as an argument for forcing a prescribed IDE on team members. You mention scaffolding tests, things like this can be left to external tools and then it works for all IDEs and all editors. Then you can let people use what they find most ergonomic.
- zo1 5y ago
  Not OP. But having to sit for an hour watching some Vscode dev struggling to run tests or get auto complete on some random function is a waste of time. They spend more time faffing about fixing and fiddling with that than it would take to install a proper IDE and load up the same project and have it 100% work. Like I get it, some people know their language inside and out and can fix it in a second because they know all the pitfalls and inner workings of the tool chain. But 99.5% of them don't, yet when they fix it they act like code ninja messiahs because they configured some random json config file after googling it and it worked. That's all I see Vscode users doing.
  - Lio 5y ago
    Against though that sound like more of the same argument. If you set up external tooling to run the tests you can just tell them to use that with nothing to set up. Either way whatever tool you use, nothing can be worse than pairing with someone who copies and pastes with a mouse. I can just feel my life ebbing away as my inner voice screams “LEARN THE SHORTCUTS” and they slowly move 3 characters across the screen, make a mistake and try again. :P
- oneplane 5y ago
  I mentioned that because in 2005 that was a real PITA and the first example that came to me. It's not a 'real' problem in Greenfield problems today. It also isn't really the point, but just an example for people who don't get the point (and apparently not a good one at that). The point was: if you make it difficult to work together because you have a high horse / hill to die on / unique incompatibility, it makes teamwork unreasonably hard and inefficient, which becomes a problem as soon as time and/or money is involved. The "haha I am so much better because I don't use an IDE" line of thought falls within that category. So does "I run TempleOS so that my code is blessed" and "I don't like git so I use TFS and you can all suck it". Now, say you have something much easier to not care about tools; i.e. a gitops driven workflow for your terraform code. Then it doesn't really matter what you have locally because until your code is merged it is in no way/shape/form going to create a problem. On the other hand, if you refused to use efficient tooling your performance might be half of what other people might present and that means the people that pay you don't get a good value from your work. Efficient tooling might mean: something that understands the syntax or AST of what you write and points out errors so you don't find out after the fact.
dolni 5y ago
Enforcing an IDE across a team for consistency is a real stinky smell. You don't have CI/CD? You sure as hell aren't going to run an IDE in CircleCI or Jenkins to do your builds.
- oneplane 5y ago
  This has nothing to do with CI/CD or forcing anything on anyone. It has to do with being similar enough in a team to be able to work together. Being unique or different to a degree that it is hurting your (and by extension your team's) performance is bad.

deleted 5y ago

[deleted]

Lio 5y ago

I don’t quite get this as an argument for forcing a prescribed IDE on team members. You mention scaffolding tests, things like this can be left to external tools and then it works for all IDEs and all editors. Then you can let people use what they find most ergonomic.

zo1 5y ago
Not OP. But having to sit for an hour watching some Vscode dev struggling to run tests or get auto complete on some random function is a waste of time. They spend more time faffing about fixing and fiddling with that than it would take to install a proper IDE and load up the same project and have it 100% work. Like I get it, some people know their language inside and out and can fix it in a second because they know all the pitfalls and inner workings of the tool chain. But 99.5% of them don't, yet when they fix it they act like code ninja messiahs because they configured some random json config file after googling it and it worked. That's all I see Vscode users doing.
- Lio 5y ago
  Against though that sound like more of the same argument. If you set up external tooling to run the tests you can just tell them to use that with nothing to set up. Either way whatever tool you use, nothing can be worse than pairing with someone who copies and pastes with a mouse. I can just feel my life ebbing away as my inner voice screams “LEARN THE SHORTCUTS” and they slowly move 3 characters across the screen, make a mistake and try again. :P
oneplane 5y ago
I mentioned that because in 2005 that was a real PITA and the first example that came to me. It's not a 'real' problem in Greenfield problems today. It also isn't really the point, but just an example for people who don't get the point (and apparently not a good one at that). The point was: if you make it difficult to work together because you have a high horse / hill to die on / unique incompatibility, it makes teamwork unreasonably hard and inefficient, which becomes a problem as soon as time and/or money is involved. The "haha I am so much better because I don't use an IDE" line of thought falls within that category. So does "I run TempleOS so that my code is blessed" and "I don't like git so I use TFS and you can all suck it". Now, say you have something much easier to not care about tools; i.e. a gitops driven workflow for your terraform code. Then it doesn't really matter what you have locally because until your code is merged it is in no way/shape/form going to create a problem. On the other hand, if you refused to use efficient tooling your performance might be half of what other people might present and that means the people that pay you don't get a good value from your work. Efficient tooling might mean: something that understands the syntax or AST of what you write and points out errors so you don't find out after the fact.

dolni 5y ago

Enforcing an IDE across a team for consistency is a real stinky smell. You don't have CI/CD? You sure as hell aren't going to run an IDE in CircleCI or Jenkins to do your builds.

oneplane 5y ago
This has nothing to do with CI/CD or forcing anything on anyone. It has to do with being similar enough in a team to be able to work together. Being unique or different to a degree that it is hurting your (and by extension your team's) performance is bad.