I tend to slightly disagree. Some of my most valuable learning was taking on massive projects, and then just doing whatever I could to make it work. Of course, progress would be slow, and you'd need to chunk up the problem and take small steps, but it rarely felt like slowly building up or climbing a staircase.

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.

I actually disagree with both of you. Programming is learning and the code is the side effect of what you have learned. If you jump at a large project but lack the fundamentals you are going to wasting energy on stuff you shouldn't be.

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)

> If you jump at a large project but lack the fundamentals you are going to wasting energy on stuff you shouldn't be.

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.

The best way to learn programming is to read and understand other programs.

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.

> If you jump at a large project but lack the fundamentals you are going to wasting energy on stuff you shouldn't be.

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

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

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 isn't really my experience. I learnt ASM because I wanted to reverse engineer a C binary. I learnt kernel stuff because I needed to write a device driver. I learnt low level networking by writing an HTTP server in C. I learnt programming language design by writing my own programming language.

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.

From what I've observed there's different ways that people cope when they find themselves in the deep end. Some try to learn and understand everything they can about their new environment (this seems to describe your experience), while others just try to find a working solution for their immediate task.

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.

Yes. I learned that about myself a long time ago. Sometimes it takes me a week to figure out "how to change the color of a button" but after that I can ramp up pretty fast. As I get older it just becomes a question of targeted time investment strategies. Where do I want to invest that week?

The issue is mostly when the steps are not conventional, too high, tilted, slippery, behind thick fog. Suddenly you have a new problem, learning to climb in new ways.