Learning CoffeeScript was only a waste if you never got paid to write / never built anything useful in CoffeeScript.

The failure there is learning something that is not useful to you right now, not "learning something new".

Are their opportunity costs associated with learning one thing over another and making the "wrong choice" in terms of which stuck around longer? Sure. But you can't predict the future. Focus less on what you learned that didn't get much mileage, and focus instead on what you can learn next. Learn new things and old things - just keep learning! In the end, there are very few things you can learn that are a total waste of time - the more things you learn, the more perspective you have, whether or not you are specifically using the exact thing you learned.

Exactly. Also, things keep getting reinvented, often with something beneficial added but usually also something worse than what we used to have. So the perspective of past knowledge can often help you understand some aspect of the new stuff, if you’re also correspondingly open-minded enough to learn the new thing on its own in advance.

And recent experience has shown me that you can both be working with the worst legacy code and CGI has to throw at you and also having to learn pre-release ECMAScript and TypeScript, to use on the same project. Some skills transfer — I’ve never had to fully relearn how to loop through something in a new language once I managed to master both for loops and map/each functional approaches, for example.

Other things are maddeningly poorly developed — tools to help you understand and refactor code are still very much language-specific at the moment and it’s always a one-off to port out-of-fashion languages and syntax to newer ones. Let’s not start on how testing guidelines and TDD haven’t significantly changed since 2003 unless you maybe include SRE work and better “testing in production” techniques... Some knowledge seems evergreen... or stale.

But it’s amazing how when you do keep an open mind, and focus on how something really works at a lower level, it still pays off over time. I still haven’t deployed anything in production with Docker and K8S but that doesn’t mean it wasn’t worth learning, it helped clarify that there’s more to production reliability than simple deployment scripts or imperative commands vs declarative repos — simply knowing it helped me better understand related topics, including additional reasons why immutable, fully-reproducible build systems are a good thing, or how deployment can be seen as a complete system instead of simply “what version of the code is on the servers now?” It also provides a promise of a cloud-agnostic future, and an alternative look at why 12-factor was good, but incomplete.

And there, again, one might say, why did you bother learning 12-factor when most places let you store log files on local EC2 drives, for example? Well, because if you can get over the information overload, having multiple ways of doing things means you’re more likely to be flexible in your approach, or ask “why” when someone says “just do it this way”. It of course has to be balanced with healthy pragmatism, to both ignore the “best option” when it’s too much work, or to recognize that there’s always a chance to continue improving things later on, or as a team.

What’s key is trying to think strategically about your code rather than tactically. A tactician would say “learning nothing new outside of what I need at this moment gets the job done faster” or “this fixes the bug” while a strategist recognizes that there’s always a future opportunity cost, or asks, “but what caused the misunderstanding that allowed it to occur in the first place?”

Also, it’s inevitable that things will change, so you should always either keep up with your specialty or keep expanding your generalist skill sets. And even your knowledge isn’t constant — there’s always something to re-learn if you haven’t used a thing in awhile or in some new way...

So yeah, React may go away in three years. Do you think you would have been better off during those three years continuing to use jquery? Do you think the hours spent learning the new thing were more or less then the hours saved my the new thing having a better api?

(now, of course, you I may be wrong on the cost benefit analysis here. I don't think I am, and the ubiquitousness of the new stuff implies that most of the industry agrees... but no matter the answer, that is the way to think about whether learning something is worth it)

I have a different opinion. Anything learnt will improve your thinking and help you learn new things. A kid who goes on to become a truck driver might never directly use algebra on the job, but learning algebra has shaped their brain and will help in all areas of their life.

Absolutely agree with mastering SQL.

Out of all of the languages I have learned over the years, only one has stayed important in every job and mostly static - SQL

There are many languages and libraries, but at this moment in time, all of them have to talk to a database at some stage, and in order to do that all of them convert the request to SQL.

Yeah true. As a business analyst I have queried many databases, but SQL doesn't change (much), and the dialects share a common base, even for the cloud based ones. My bread and butter.

I prefer learn tech on demand: given a job find the right tools that exist at the time, and then use them even if you don’t already know them.

Besides, having problem context makes the learning much easier, vs just saying...I’m going to learn react today in a void.

> given a job find the right tools that exist at the time

If you don't know said tools beforehand, how can you be sure they are right for the job? When building a new website, for example, should you reach for jQuery? Or is React right for the job? Or is Vue even more right? Or will it be Svelte? Or is vanilla javascript the tool that you really need? How would you know?

> Learning JQuery helped me for a few years, but now JQuery is basically useless to me.

'A few years' is a solid return on investment. Besides the reason Jquery is now useless is because Javascript now has those capabilities, so your skills were 'grandfathered' to ES6/ES7.

Learning an applicable skill is almost never useless.

Yeah, I'm not saying it wasn't useful at the time, just that it's not useful now. As opposed to learning SQL or shell scripting which will probably be useful my entire career.

I'm convinced of 'learn old > learn new' in general, but I think there are some interesting edges: the older something is, the larger the gap (maybe chasm) will be between 'basic competence' and 'venerable expert'. Also, the more likely all the common problems you'll face will have been posted on the internet, and that the quality of tutorials and explanations will be superlative.

While the payoff of learning old > new is typically much higher (search: Taleb Lindy effect), I think matching your learning to the 'human api' is more important. For me, learning is very emotional: when I feel a sense of curiosity and intrinsic drive to know, I'll follow my nose, spend my time where it takes me. I want to spend this kind of energy in a certain way.

When I find myself with an instrumental cause or external need to know, it's most likely going to be because it's something typical, something old, in which case learning about it and being useful with it will require less of my spirit and drive to crack.

New language/tech fanatics tend to pressure through both sources (a la "look at our ingenious design breaking paradigms" and "it's so good your boss will want you to work in it (well, soon)"). Often the former argument is stronger, so it appeals to your curiosity - in which case you're best off searching for the useful kernel, followed by a swift exit in order to preserve your sense of discernment. Should you return there, provoked by your general interest, that ought to be your indicator of importance. How hyped you felt that one afternoon you learned about it after reading HN comments is likely not.

On the other hand, the 'should learn' brigade will tend to target the latter source of pressure (employability & centrality). If you find yourself feeling resistant to this and force yourself into it anyway, you'll easily burn out and douse your curiousity for the day. I've arranged learning resources to languages I find fundamentally dull multiple times, and made only very shallow dives into them.

When choosing what to learn, your built-in heuristics will tend to serve you much better than either a long list of common 'shoulds' or a tangle of overhyped 'musts'. Let natural forces do their thing in shaping what things will be presented to you: avoid paying much attention to the loud people where marketing, shills and zealots tend to roam.

I made the switch to vanilla JS from jQuery a year or so ago and it's great to see how jQuery (and other libs) pushed vanilla in certain directions. But I'll always miss $('#element') vs getElementById('element') and similar shortcuts.

I agree about 90%. Sometimes though, it pays to learn the weird or new stuff. Sometimes, you can make a lot of money knowing the next big thing, even if it goes away in a year. You have to be well positioned though, like being an hourly contractor.

I'm generally the guy who knows the boring shit. C, networking, 'Linux', hardware, RF... But I keep telling myself I'm going to jump on the next bandwagon just to see how the ride goes.

The concepts behind some things like React will last. I have seen several incarnations of GUI event frameworks and once you learn one, it is easier to learn others.

That said, some technologies are fads that learning them for the sake of learning doesn't have a big payoff. I learned TCL at one job and have never used it again. There will always be things you learn for software development that proves to be dud. Get used to learning and be happy when something has long term success. It is vary hard to predict that the long term success will be.

> but now JQuery is basically useless to me.

Probably not, because even if you don't use it today, the problems and solutions you learned while using it probably made you a better developer and you know what was good and not very good about it, so even if you are making something with React, you probably remember the "old jQuery days" and don't make the same mistakes.

I assumed unix would last, but lately there is the concept where “the cloud is your OS” and I hope that isn’t true. I like Unix. However, I’m wondering just how much of what I type in the future will revolve around cloud apis and tooling instead

> Avoid Learning Anything New – Learn Something Old

That is exactly how I understood it.