I think the trial by fire approach, just jumping into the deep end, is a much more effective way to learn. It's also more fun for me.
Rather the best way to learn programming I find was to master the basics, memorize the most used routines and commands to avoid having to google it every time (ex. CSS)
The problem now is we have LLM which kind of negate the need and we have lot of engineers who don't have good fundamental systems design.
The other major issue is most of us engineers are scaling for a future that won't come. It's sufficient to squeeze ton of performance out of a single vertically scaled Postgres instance for example without the need to do exotic architectures.
So prerequisites are important like in the article but less so now but the fundamentals and only learning what is needed is critical more than ever (ex. Kubernetes for a blog)
It's a really fun field, and you can isolate yourself and get very deep into thought, and then enter an exceptionally rewarding period of cycling between work and learning. I think a lot of programmers eschew more sensible things in favor of exclusively working in this mode.
"Wasting energy" in this case would be learning. This learning happens faster than following a tutorial and "mastering" the basics.
> The problem now is we have LLM which kind of negate the need and we have lot of engineers who don't have good fundamental systems design.
Yeah if you use LLMs for everything you are just going to struggle 10x harder when you encounter a problem. This does not discount my point.
Also why is your name a slur.
On the other hand, for many people (like me!) it can be hard to feel motivated to learn a new programming language/framework/etc just for the sake of it (especially when you've got plenty of stuff going on already). (Note that I use "motivation" here in the immediate, executive function sense, not in the broader desire to do a thing sense.)
In such cases, I have found that the best way to learn how to do what a large project requires is to first define the project that you want to accomplish that uses them, and then break that down into all the parts you need to learn to make it happen.
The outcome is still "mastering the basics" before you actually take on the large project as a whole, but it can still look very much like trying to tackle the large project from some angles.
If people survive it this gets them past some substantial mental hurdles. People who take too long on the basics often get stuck in the beginner treadmill, not really progressing but getting better and better at those basics.
Unfortunately, it's not perfect. Most of my colleagues who have taken this approach have deficient mental models of how computers work or are missing significant portions of background or fundamental knowledge.
After the trial by fire, you have to go back and fill in the gaps, hopefully deliberately and not just by future trial by fire efforts.
This was, of course, before LLMs, but I don't see how I am missing "fundamentals." They generally come if you are building something non-trivial and are genuinely interested in technology.
In my experience, the first approach is extremely effective, even if it can sometimes result in analysis paralysis. However workplaces almost always prefer the latter so it can be hard to fill in the gaps later.