Learning How to Learn Used to Be Enough

About twenty years ago I sat on a committee at a local college called the Web Technologies Advisory Committee. The job was straightforward: tell the school what to teach students who wanted to build websites for a living.

Every meeting came back to the same question: should the curriculum focus on Flash, or Dreamweaver, or whatever framework was hot that semester? The educators wanted specifics. Give us the tools, they said, and we’ll build the courses around them.

I pushed back every time. My argument was simple: teach students how to learn, because the specific tech was going to be obsolete before most of them graduated.

The underlying practices, the software development cycle, version control, how to debug a problem methodically, don’t change nearly as fast. Learn those well and you can pick up whatever framework shows up next. That advice held up for the twenty years that followed, but it isn’t the whole answer now.

What happened

Twenty years is long enough to check the prediction against reality.

Start with Flash. Macromedia bought the company that built it and renamed the product Macromedia Flash.¹ Adobe bought Macromedia in 2005² and shut Flash Player down at the end of 2020, pointing at open web standards that do the same job without a plugin.³

The same thing happened to table-based layouts, browser-specific hacks for old versions of Internet Explorer,⁴ the XHTML 2 effort,⁵ Silverlight,⁶ and Flex.⁷ All of it is gone or irrelevant now. A student who spent 2005 mastering Flash ActionScript learned something with a shelf life of a few years.

Even jQuery, which dominated the web for over a decade, has faded out of new work. It launched in 2006, when selecting elements or handling events reliably meant fighting inconsistent browser APIs.⁸ Modern JavaScript absorbed most of what made it necessary.

It still runs on roughly two thirds of all websites, and 23.4% of developers did extensive work with it in the past year. Only 31.4% of those users want to keep using it, among the lowest scores in the web framework category.⁹

Other things didn’t become obsolete at all: knowing how to plan a project, how to read someone else’s code, how to break a problem into pieces, how to figure out what you don’t know and go find out. Those skills carried straight through Flash, jQuery, React, and whatever comes after React. The committee argument held up.

What AI changes

The advice was right for the twenty years it covered. What it missed is a failure mode that didn’t exist yet.

Speed is the least interesting part of this. AI can now produce the specific-tech knowledge itself.

You don’t need to have memorized React’s hook rules or jQuery’s selector syntax when a model can generate correct syntax on request. Recall of syntax isn’t worth much anymore.

That sounds like it strengthens the original point: learn how to learn, let AI handle the syntax, focus on the durable skills. It mostly does, but there’s a failure mode the old advice never had to account for.

A student can ship working code today without ever debugging it and without breaking the problem down themselves. The model did those parts. Nothing in the result tells them the skill never developed.

Using AI well takes a skill layered on top of the original advice: judging output you didn’t produce. Knowing which architectural choice causes problems six months out, and when to override a suggestion rather than take it, comes from having made those calls badly before.

If I were back on that committee today, I’d keep the original advice and add a line to it: make sure students still do enough of the work themselves to develop judgment about the work AI does for them.