> You only like to work with experienced engineers, who are already experienced with the specific tooling you use on your projects fine.

That's not what I said at all. Inexperienced in general is fine. I benefited from mentorship earlier in my career, and I'm happy to pay it forward.

Inexperienced with my specific tooling is a weird point to make, because it directly contradicts my point. If you teach people how things work: the underlying computer, OS, system libraries, and teach people the nuts and bolts of how to do their jobs: version control, the command line, filesystems, etc., then I especially don't care if they've used my specific tooling before, because they probably have enough foundational and background knowledge to be able to pick up different tooling and languages without too much trouble.

The people who are just taught to open an IDE, click "new project", and never leave the IDE, are the kinds of people that I expect will have trouble if they join my team and we're using different tooling than they're used to.

It's always felt to me like, "Oh you want to learn to cook? Great!" This is a pickaxe. I want you to mine some iron slag out of this vein.

"What does this have to do with cooking?"

"Well, you want to use a knife to cut your vegetables don't you? How on earth do you expect to get a knife to cut your vegetables if you don't mine for iron slag, refine it, build a forge, learn blacksmithing, make thousands of inferior and useless knives until by trial and error you finally have a knife you can cut vegetables with!"

"Ok, so once that is done then I can be a cook, right?"

"What? are you a fucking moron? Look at this asshole who thinks he can be a chef if he knows how to make a knife! What an idiot! You need a pot and a pan and a kitchen, but to get a kitchen you need a house and to get a house you have to buy the land and then to get the food you have to learn agriculture and animal husbandry, woodworking, stone-masonry, how to quarry, political intrigue, bartering, build a working economy you and 7 other people can all agree on using..."

It isn't that difficult. All I really needed was a problem and a line on the tools I needed to solve them. All the other stuff may make me competent should I need to rebuild the world's technology stack from the ground up a.k.a Dr. Stone but it never earned me a dime of income of served the most basic of purposes in attempting to dissuade me from a computer career.

I agree and also feel like Students new to computer programming shouldn't be using Eclipse. They should be learning the fundamental concepts and their implementation, and having to learn a whole very complex IDE as well would just add to that difficulty.

What fundamental concepts?

if, while, and other programming concepts? I'd agree on that.

But the article suggests learning about files, file formats and other low level stuff.

So maybe they should first learn how a filesystem works, how it keeps internal consistency, and how the bytes are mapped into some physical storage. That's pretty fundamental too, right?

What we have here are "leaky abstractions"[1]. If the abstraction an IDE provides is not good enough that students can work with it without knowing about the lower layer, then the abstraction is leaky. And that is the problem. Not "should I teach them with an IDE or without".

[1]: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

> What we have here are "leaky abstractions"[1]. If the abstraction an IDE provides is not good enough that students can work with it without knowing about the lower layer, then the abstraction is leaky.

Do you suggest teachers fix Eclipse so it no longer has leaky abstractions rather than just teach students how to work in a modern file system?

I agree with you. For example, in an algorithms class they need to focus on the right things such as O() and not on the Java compiler or the Python interpreter or even worse (god forbid) on gcc.