> you say that, and just last month I've had to help a guy manually remove an import of Token class from a wrong package that "magically broke his code" :)

Hmm, the IDE should offer you multiple classes to import from in a dropdown if there's any ambiguity, as well as highlight any of the methods that aren't present or whose signatures differ and provide popups with essentially the same information that you'd get from the compiler, without even having to compile the project. In that regard, i'd say that IDEs are actually superior. A single ctrl+click that'd take you to the source of the class that you've imported should also clear up any confusion about the import.

Importing the wrong thing and not bothering to figure out why their code doesn't work honestly feels like not being familiar with the language itself (as opposed to the tooling) and for some reason not trying to figure it out on their own by reading what the IDE is telling them - to me, that does sound more like learnt helplessness than anything else, which would also manifest itself when writing code and running into design patterns that they don't understand, as well as any number of other situations.

> Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :)

To me, this also feels like more of an organizational issue: if companies don't have a RACI matrix (https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) and have a low bus factor (https://en.wikipedia.org/wiki/Bus_factor), then that's on them. If no one takes initiative and the company fails to find employees who will, that's also on them. If only one person understands how things work and doesn't document it, nor are there processes in place to ensure any sort of knowledge transfer, then that's also on them.

That does sound like a dysfunctional environment and at that point builds will be the least of your worries - figuring out how to get code to prod, how to work with the DB and run tests (if any are present), as well as any other steps that haven't been formalized with an "Infrastructure as Code" approach will cause far worse problems down the road. Good luck if any of your servers ever go down and you haven't used something like Ansible for configuring them, but instead it was done N years ago by someone who's long gone along with their knowledge about how to do that.

If you work in such an environment and care about personal success, consider either changing the company or changing companies.

> Importing the wrong thing and not bothering to figure out why their code doesn't work honestly feels like not being familiar with the language itself (as opposed to the tooling) and for some reason not trying to figure it out on their own by reading what the IDE is telling them - to me, that does sound more like learnt helplessness than anything else

To be fair they have 30 files open in the IDE and 100 lines are highlighted cause of spelling errors, it's easy to miss the line highlighted in red as opposed to yellow or black. If you look at the console output you will know the reason build failed immediately, but that's hidden behind 5 different things begging for your attention.

It is learned helplessness, but there's a reason people learn it - they went straight for the industrial tools with dozens of variables that were never explained. They never learnt how it works under the hood and what all the knobs do. They were taught to follow the tutorial, ignore the warnings, leave the defaults as is and click the big green triangle to run the program. 99% of the time it works and when it doesn't maybe start from the beginning again and follow the tutorial more carefully :)

It's a generalization of course, there are people who problem solve better and worse in any demographic, but in my opinion the tendency is - depending on tools and automation early in your education makes you a worse problem-solver.

> If no one takes initiative and the company fails to find employees who will, that's also on them. If only one person understands how things work and doesn't document it, nor are there processes in place to ensure any sort of knowledge transfer, then that's also on them.

There's organizational goals and processes, and there's company culture. The latter is far more important in practice. And it's mostly shaped by the attitudes and expectations of people, not by putting a document on company's wiki or talking about it in a meeting.

> To be fair they have 30 files open in the IDE and 100 lines are highlighted cause of spelling errors, it's easy to miss the line highlighted in red as opposed to yellow or black. If you look at the console output you will know the reason build failed immediately, but that's hidden behind 5 different things begging for your attention.

Then why not address those things first? Most IDEs should allow you to set up inspection profiles or customize the spellchecker and version this configuration so all developers would get a consistent and noise free experience, just like you should be doing anyways when not using an IDE but instead using a code editor together with a linter/formatter and Git hooks.

JetBrains products are actually pretty good in that regard, personally i've sometimes enabled almost all of the warnings, apart from some of the conflicting ones, just to learn about more concerns that i would have otherwise not thought about myself. Not that most people should do in their everyday lives when they want to get things done, but being able to do so is nice.

> They were taught to follow the tutorial, ignore the warnings, leave the defaults as is and click the big green triangle to run the program.

That sounds like that joke about everyone ignoring 99 warnings within their project because the code compiles and runs. Once again, i do believe that this is a bit orthogonal to the IDE vs code editor debate, because if there are warnings within your project you should address them regardless of the tools that you use. If it's a bad tutorial, then why are you using it?

Of course, one can also talk about how defaults should be sensible and the default configurations/examples should never have warnings, but i guess that's just what you get when people don't pay attention to the quality of the things that they make, which is at the very least understandable in our current world.

> It's a generalization of course, there are people who problem solve better and worse in any demographic, but in my opinion the tendency is - depending on tools and automation early in your education makes you a worse problem-solver.

This is an interesting argument. I don't necessarily agree that the automation is the cause for this, merely a canary of sorts. Perhaps the people who don't have the patience to struggle with the "traditional/old" way of doing things would simply not stick around in the industry for long (this probably applies to situations where they'd have to write ASM instead of Python, as an example) due to the frustration they'd experience with all of it and not getting any demonstrable results early on, which is extremely discouraging, as opposed to the more patient and persistent people? In that regard, IDEs indeed enable a wider variety of people to stay within the industry.

I cannot comment on whether that's a bad thing or a good thing, much like some people said that we'd not always have calculators with us and yet almost everyone does have a smartphone in their pocket.

> There's organizational goals and processes, and there's company culture. The latter is far more important in practice. And it's mostly shaped by the attitudes and expectations of people, not by putting a document on company's wiki or talking about it in a meeting.

This is debatable. Those two are not mutually exclusive. Look for environments where both live up to your standards and contribute to both in a positive way.

I certainly have, for example, in one of our projects now all of the configuration lives in Git and is managed through Ansible, so we know when, why and who changed things. I've also made running services more consistent, have containerized apps to get rid of the dependency hell and have written plenty of scripts for automating the bits where people made mistakes, e.g. long DB migration names that need a particular format like V20211107.5.4.2.21.1.0_Alter_Some_Table_Do_Something

At the same time i've also onboarded new people, helped them get started and have explained things both about the projects as well as things in the industry in general, as well have pointed them towards useful learning resources. Being pleasant to work with and having a healthy environment doesn't need to come at the expense of anything else, apart from maybe people's egos sometimes (including mine).

Of course, no one wants to do things for just putting a checkbox in some corporate form, but in practice most of the meaningful ways to minimize risks and make people's lives easier down the line are worth it and there are no excuses not to implement them in any mature company. That's why having documentation and enforcing that it's present is a good idea, especially if you do IaC and most of it is actually code, that's commented as well as the rest of your codebase should be.

You realize the IDE relies on the compiler to do all that magic stuff, right? So when you get to the point where you have a build error because some odd/unexpected import/target all of a sudden everything in the project is an error and the IDE is suddenly not so helpful.

> So when you get to the point where you have a build error because some odd/unexpected import/target all of a sudden everything in the project is an error and the IDE is suddenly not so helpful.

This has not been my experience, at least with IntelliJ in the context of Java projects. Bad imports result in IDE highlighting the erroneous usages of the imported class, by showing which methods aren't available. The red squiggles provide immediate feedback and let you know whether any problem lies within the method parameters, or whether the method itself isn't found, before you try to compile/run anything manually. Tooltips about the error contents are also pretty useful, no need to manually go to the file/line based on some text output in a terminal.

Bad language targets/JDK choices are far "louder" as far as the amount of errors output go, but they're easy to figure out, since if you ignore everything being red in the IDE and instead try to compile the project, you'll get the exact same output that the compiler will generate. It's just a matter of Googling those errors, regardless of how you compile your projects.

The only problems of such sort that i've run into have all been because of the Spring framework and its configuration mappings not being detected properly because some developer decided to initialize it in a non-standard way which confuses the IDE. Then again, using a code editor instead of an IDE wouldn't really provide any useful functionality/hints for Spring either, so i guess that ended up being roughly equivalent.

I should preface that my experience primarily comes from Scala and dotnet, I don't really use Java.

Sure you can play Google whackamole but a lot of times the compiler message alone isn't going to help you and when you Google the message you there are 20 questions on SO where the top answer has 1000 votes and says something like, delete the bin folder and restart.

But that's not the issue. The issue is your importing two projects that are targeting different dotnet frameworks.

The dependency project builds fine on its own.

They project using the dependency just loudly proclaims that the imported type doesn't exist.

Rider gives you a few squiggly lines and tells you "Computer says no"

You yourself have to figure out that one of the projects has changed targeting framework while the other one hasn't