Thanks, yeah I quickly read through the pieces you mentioned. Totally agree. We are very much of the same mind on this.

As you say this principle applies to so many areas of life. I developed a strong aversion towards all sorts of libraries and tools when I worked as an iOS developer.

We to all these projects to take over writtene by what was often former JavaScript developers. They seem to be really framework trigger happy over there.

The tinies iOS apps got tons of dependencies. Often to libraries that quickly got abandoned and then we had the mess of trying to deal with libraries which had become obsolete because they had not been updated to the latest iOS version.

This desire to take shortcuts with libraries, created so much more long term work.

I remember a particualar agregious case, where I sad debugging a multhtreaded external library for doing regular expressions, validating email addresses in our app.

After what felt like hours bangging my head in the wall trying to figure out some crazy race condition, I suddenly had a moment of clarity: "Why do we need a multithreaded library to validate a fricken email address!!!!"

So I threw out this stupid dependency and wrote the validation from scratch. It was ironically much shorter code and writing it from scratch was faster than debugging the mess I had inherited.

I had so many experiences like that struggling with maintaining software until I realized that everything could be dramatically simplified by throwing out lots of external dependencies which actually did fascinatingly little.

When it comes to teaching, I also believe in your method. Teach the core library and constructs. Fancy external libraries and frameworks that simplify your job should only be taught once you know the fundamentals.

These things don't really pay of anyway until you write lager software, so it is not like you really need to know it as a beginner.