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.

But a sane person doing this would arrive at single logical solution: focus on server-side and ask company to hire a 27-year old JavaScript "ninja" to handle the front-end garbage framework of the month, while you are hacking OCaml/Scala/Haskell whatnot.

It always makes me chuckle when I see a job posting that clearly states it's JS front-end only: some old dogs know the trick ;-).

Pro-tip: re-write one of less significant systems in Node.js as a decoy!

What are some examples of core technologies?

ColdFusion! It's been dead longer than I've been developing with it; but is still going strong. :ha, ha:

Seriously, though, I would not say there are any core technologies; but rather core programming concepts.

Variable memory management is one example. Knowing the difference between passing parameters by value, or by reference, when writing Lotus Notes applications actually helped me understand the difference between a variable assignment and creating a deep copy in JavaScript.

Less specific; If I had to guess--in 20 years; I'll still be working in technology that supports things like MVC(S), Dependency Injection, Singletons, Factories, etc....

Learning basic encapsulation techniques, and design patterns, is knowledge that will apply to lots of programming languages.

Unix, git, networking, C, HTTP/HTML/CSS/JS, databases, blockchains, data structures, compilters, most things in a CS curriculum, etc...

I saw an amazing presentation at a ruby meetup about database indexes for developers (for example). Will see if I can dig it up.

Here you are. The slides aren't as good as the tall (as you'd expect) but still may be helpful.

Other core technologies (in my opinion): cookies, http, TCP/IP, caching.

Ack, forgot the link: https://speakerdeck.com/heimir/databases-for-developers

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.

- Maybe api:s aren't meant to last, maybe rewriting more is the piece missing from the puzzle. Always leaving evolution up to others doesn't really work if we all do it at the same time, and your brain is as good as mine when it comes to recognizing truth.

- Picking frameworks is a bit like picking presidential candidates, the whole game is rigged from the start. Once upon a time software was about solving problems, about working creatively based on your own experience. We can still learn from each other, and share code; but I feel the push towards standardizing on over engineered, general purpose code is misguided; like we're staring at fingers pointing at the moon, arguing which finger is the perfect one.

- New frameworks arise because needs aren't being met by the current status quo, hence we need innovation to get out of here. Where did this obsessive focus on popularity come from, anyway? I couldn't care less who did what, as long as we keep moving forward.

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.

> 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

That person would have to be (and remain so for 20) spectacularly, blissfully, implausibly obtuse ... given the minimal cognitive capacity needed to hop from each of the 20 upcoming Angular/React equivalents to the next every year will likely both suffice and entice to "osmotically absorb" said "fundamentals" behind them all over time, even when never spelled out.

I think quite a few of us grasp the principles of this or that tech first informally by trial/error and experimentation, later when reading "the spec" or the "fundamentals book" or whatever always flip-flopping between "I know, I figured it out the hard way, smart me hehe" and "I know, I know, tell me what else is new!!"

I do think learning React taught me a lot of fundamentals.

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.

Could you be more specific?

I'm not the person you're replying to, but: technology stacks live for a long time. What's hot changes, but what was hot yesterday and the day before will still be in use for many projects, including new ones, for a long time. And equally, it takes a long time for something to become greatly popular.

You're exactly right. One simple example:

Numpy for Python, Building from source:

https://docs.scipy.org/doc/numpy-1.10.0/user/install.html

"Various NumPy modules use FORTRAN 77 libraries, so you’ll also need a FORTRAN 77 compiler installed."

It also nicely demonstrates how with the new levels of abstractions we preserve the "hows" but hide them from a lot of the users.

I think he may be referring to the fact that the Angular 1 code referred to in the article will likely be maintained for quite awhile.

For example people think that everyone will or should upgrade / use Angular 1 and use Angular 4 .

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.

Why is making connections to prior experience, turning knowledge into wisdom, and gaining a unique perspective on truth. It's a completely different game than stacking facts on top of each other. Why is creative, and what is created can never be taken away; how is useless once obsolete.