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