One thing that non-Java devs don't get is just how much better the tooling is for Java than literally any other language.
Most jetbrains IDEs I find are indeed comparable to vscode plug-ins and a huge glob of vim plug-ins for most languages, especially the dynamically typed ones where the amount of static analysis you can do is already quite limited.
But for IntelliJ, literally no other editor comes close. Extract method/variable, all the "hey you wrote java 6 but it's 2024 that those 6 lines you wrote are 1 lambda now, do you want to replace", and so many other things.
Did you know that if you paste a maven xml dependency coordinate into a .gradle file, it auto-translates it to gradle format before the paste?
This is absolutely true, but having spent a lot of time The Java ecosystem and then much time outside of it, I now think this is a bit of a curse. It has made the average Java developer actually structure their code and build practices around the IDE, rather than the other way around. If it wasn't for modern CI practices which force a headless build, I wouldn't be surprised if most Java projects wouldn't even build without the IDE to do the building for them. In several places I worked, Even That wasn't really usable outside of the CI environment because it was just taped together as an afterthought and bare minimum since all the developers just used IntelliJ to build locally anyway.
Even little things like variable naming, explicit types, and the like were commonly neglected because in the IDE you could just hover your mouse over the variable to see its type. Because that exists and is so commonly used, developers didn't even think about The impact it might have on someone not using the same IDE. This is just one of several practices that I continually ran into when trying to use vim. There are also plenty of readability issues, such as enormously long methods that the IDE collapses for most developers so they never see it and don't have to think about it, but once you aren't using that IDE anymore, you really see all the nastiness and warts.
So long story short, I agree with you about the tooling, but I think it is actually more of a curse than most people realize.
Most of that could also be considered getting the best out of the tools at hand. Is it necessarily a good idea to always optimize for the highest common denominator? Even for a contributor that at the time of the decision is merely a hypothetical? That same attitude could be brought into a project by someone who refuses to use a build system and insists on everything being laid out for easy compilation by manually launching javac, or on writing makefiles instead of a pom.
I mean sure, there are projects out there where a healthy dose of tool-agnosticism should not be too much to ask for, but a generalized "they are doing it wrong" about people playing to the strengths of their toolkit is really not warranted. The opposite of structuring around what works well with their tooling is structuring around what works well with your tooling. You ask for exactly the thing you are refusing them. Yeah, IDE-only builds are a bad idea, but that's really a concept that has died a long time ago (even if there are probably a few cases around where it still has not stopped moving yet)
You're not wrong, but IME, if people are doing stuff like that, it's not something an IDE or lack thereof would solve anyway. Sometimes you just have to either train/mentor or (if unresponsive) fire people who write such primitively bad code.
I have an engineer on my team that loves RubyMine. I can't even argue with her choice... JetBrains does indeed make very solid products. I'm just not a fan though. Even still, I never want the code I write, or the tools I choose to be IDE/editor specific. Right now we're trying to figure out how to get Biome (JavaScript linter/formatter) to play nicely with RubyMine... it's not as simple as NeoVim/VSCode.
Jetbrains Goland doesn't make your code IDE specific at all. They don't do any magic, go build and everything else all works as expected from the command line. go fmt, go imports, revive, etc., can all be configured in the editor to run on save. My only complaint is that there are so many options, it takes a while to grok everything.
So instead of picking tooling that works with the dev tooling your developers like, you pick tooling that's dime a dozen (js formatter) that doesn't work with the best tools your devs like? Got it. How are you still a manager?
I'm confused at what your comment was designed to achieve. It seems like an attempt to troll. But here it is:
Formatting tooling was chosen before several members joined my team. It was chosen due to having far fewer dependencies than ESLint+Typescript+Prettier etc. One package... one setup.
Secondly, what exactly do you think managing is? Someone has to make the ultimate decision and be responsible for it. Perhaps you think a manager is someone who's constantly wandering around taking a vote from everyone on how they want to steer the ship? While I do strive to find concensus among my team that's not leading. Agree to disagree there.
In my experience VS Code (with TypeScript) even the main refactoring options don't work very well. For example when I rename a method, move a file between directories, or move methods, the imports are not correctly updated and I have to spend time fixing errors before compiling.
With IntelliJ + Java I can do more advanced refactors (change method signature for example) and it compiles without any manual effort.
Ah don't get me wrong, I absolutely agree. For advanced refactoring and bigger project, IntelliJ is very much ahead. I just think that vscode is itself far ahead of emacs/vim in that regard. It's in a middle ground between IDE and an editor once you get a language plugin installed.
