“How” ages faster than “why”

Sweeping statement from somebody whose been doing this for 35+ years. Learn core technologies. Not things built from those core technologies. Ya, you'll still have to learn the secondary stuff, but at least you have a really good idea what will NOT be around in 10 years.

This could be one of those insightful posts that elegantly state an observation in a lasting way, and one that we'll repost every few years or so as an adage on programming. But there's a few reasons why I think it falls short:

- It doesn't explore any of the reasons why the APIs -- the "how" -- age in a backwards-incompatible way. Not all cases are equal: a clean break is the surest way of dooming the old and ushering in the new, but this rarely means that old code was broken beyond all belief: even if the underlying framework made some simplified assumptions, the code probably worked okay most of the time, especially if we assume intelligent, competent developers familiar with with the underlying patterns, using a framework for its merits. A good hypothesis is that frameworks aren't solely there to help you solve problems with less code, but also to help others' understanding of the same codebase.

- Yet even the article insinuates that we can't assume the previous all the time, because many developers understand design patterns by first coding themselves into a situation where they would be sorely needed -- this happened to me, for example. The same way the article's hypothetical developers acquire enduring knowledge, I didn't understand why I'd need dependency injection until I experienced firsthand the frustrations of handling dependent objects the naive way, and found myself re-invening it independently. This leads to the possibility that not all frameworks are picked solely for their design choices, but instead popularity, code availability, ecosystem health, press, advertising, or word-of-mouth may be factors.

- If so, this still doesn't account for why new frameworks rise and all the time, which would logically begin disadvantaged by having smaller ecosystems, less popularity, less name recognition. What is there to gain by starting a new one? This is really a variation of point #1: there's a lot of subject matter to be explored here, and yet it's left unsaid.

That's why people shouldn't chase the latest frameworks but instead understand some fundamentals. Those don't change that much over time. If you just move from Angular to React or whatever other thing is hot right now every year for 20 years but don't understand what fundamentals they are based on you have the proverbial "20 times 1 year experience" instead of 20 years experience.

In a very meta kind of way, this is a great case study in the general way that humans acquire new skills and understanding. Grossly oversimplifying the research that's been done into this, we start with very specific things, and progress towards more general cases as experience and skill grow, until ultimately we (hopefully) reach a level where the fundamentals become intuitive.

Sadly, the next horrible insight a lot of people reach in the context of programming specifically is that while experienced, skillful developers can do everything the newbies can and more, for a great many commercial applications the newbie who has only the specific skills useful for a few months will cost far less than the expert but still produce acceptably good results. This explains a great many things, from the ageism and burn-out that are unfortunately all too common in our industry to the generally poor quality and often short lifetimes of a lot of software that gets shipped.

I'm hoping the next insight after that is how you fix those problems and achieve a step-change in the benefits our whole society derives from software by being able to use the extra skill and experience of the better developers in a viable way, but sadly I have yet to reach that level of enlightenment myself.

I agree that how ages faster than why but I would like to add that how ages slower than people think how ages.

This is very true.

However "why" can be very wide ranging. Sometimes it can be theoretical, sometimes it's simply due to emergent phenomena that is unescapable for various reasons

Sometimes "why" is because of anothers "how". A good example of this is how the "why" of many things can be explained by "how" C does it.

Yeah but you can't usually understand "why" before getting some "how".

This is an important point to make imo. The human brain works better at knowledge retention on the "why" category more than the "how" indeed.