I mentor/teach with an "ability outwards" approach... ie: I want to get my students a simple capability first, and then "add tools to the toolbox" second. Typically, their first project is a small webserver with a database behind it (nginx static config first, then moving to a nginx + MariaDB + $their_preferred_language stack; all on Ubuntu Server).
Since that's a non-trivial task I want to keep the details as simple as possible, so they can focus on things that matter. Typically I won't teach vi/vim/sed/awk etc. until after they can accomplish actual work within the OS. Although I see complex text manipulation as important, I see it as additional tooling vs. a concept they can anchor their learning experience to.
> Nothing wrong with an immediately steep learning curve it's only hard until it isn't
I read this as "throw em in the lake, they'll learn to swim" vs. being honored to help them start in one of the most powerful ecosystems I've ever been privileged to build in: Linux.
The task at hand is to learn basic linux. You shouldn't be editing server configs or performing other higher level tasks until you have at least a basic competency at using the system, and learning text editing with vi is one of the most basic and useful skills to have since it's ubiquitous.
The reason I'm so opposed to this teaching philosophy is that "just get started developing"-first approaches instead of admin-first invariably seem to lead to sloppy and/or insecure products, and you end up with yeehaw "chmod -R 777 to make it work / SELinux is a hassle, always turn it off" developers that have to be painfully retrained once they get into the real world (or worse, are left to their own devices and you end up with horror stories like unsecured databases being exposed to the internet with PII or PCI stuff stored in it).
It is impossible to develop good quality software if you don't understand the platform you're building on top of, and the concerns of the people who'll end up using your software.
>I read this as "throw em in the lake, they'll learn to swim" vs. being honored to help them start
I see your approach the same way - skipping the basics and throwing them in at the deep end. So many projects suffer because of lack of knowledge about systems administration, basic networking, security, etc.
In my experience all of this knowledge happens "on a journey" vs. treating it as an ideal set of skills. Hence why we have student/intern/junior/senior/architect levels and the like. I review the heck out of junior level work and often find opportunity to help them improve.
I start people off at being able to accomplish something as I find it to be more motivating to keep them learning all of the things you mentioned.
If you're expecting me to have someone at a PCI level (which I am) as a junior you're missing the scope of what I mean when I say "honored to help them start". It took me years to be competent enough to handle PCI as a dev/admin!
Sorry I start with nano and simple web server configs =/
