4 ms·

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 too

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

by Lio 5y ago

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.