Nothing Here Will Last (Learn It Anyway) #

Why Temporary Knowledge Still Compounds #

I gave this talk at a computer science colloquium today. Time got away from me on stage, so here's the full script. One day I shall learn how to give a prepared speech.

The Graveyard #

I want to start with a list.

PhoneGap. BlackBerry. Windows Phone. MFC. ColdFusion. Objective-C (mostly). jQuery (increasingly).

Here's what this list has in common: I have shipped production code in every single one of these. Real code. Code that customers paid for, that clients depended on, that I stayed up late debugging and was genuinely proud of.

And every one of them is a tombstone.

PhoneGap was discontinued. BlackBerry and Windows Phone, the platforms themselves are gone. Not the frameworks. The phones themselves! MFC is on life support inside Microsoft. ColdFusion… If anyone in this room has written ColdFusion, find me afterward, we'll form a support group.

My name is Tim Doughty. I've been a professional software engineer for over twelve years. I've worked in data recovery, environmental science, and banking. And in that time I have watched more of my hard-won knowledge expire than most of you have had time to acquire.

So here's the uncomfortable question this talk is built around. If everything on that board is dead, if a meaningful fraction of what you're learning right now will be dead within a decade, why bother?

Why learn any of it?

I'm going to spend the next forty-ish minutes convincing you of something that sounds like a contradiction: everything you learn in this field will expire, and learning it is still the single best investment you will ever make. Not despite the expiration. Almost because of it.

The thesis is this: knowledge is temporary, but the compound interest on learning is permanent. Every dead technology on the board left something behind in me that is still paying dividends today. The tools rot. The residue compounds.

By the end, I want you to look at that graveyard and see it the way I do: not as wasted effort, but as a portfolio.

Let's start with why this problem is worse than you think.

The Half-Life Problem #

Let's put numbers on the anxiety.

Your career, if you stay in this field, is going to run about forty years. Maybe more. Now think about the dominant technology stacks of the last forty years and how long each one stayed dominant. Mainframe COBOL. Client-server C++. The LAMP stack. Ruby on Rails as the default startup choice. jQuery as the front-end. Angular, then React. Each of those owned the world for five years? Eight, if it was lucky?

Run the division. A forty-year career divided by a five-to-eight-year dominance window means you are going to fundamentally re-tool somewhere between five and eight times before you retire. Not "learn a new library." Re-tool. New paradigm, new ecosystem, new set of instincts.

Here's my own timeline as evidence. I graduated from Sonoma State in December of 2013. Computer science degree from this very program.

Almost nothing I use daily today existed in my coursework.

React? Released the year I graduated and I never touched it in school. React Native, which I've now used to ship apps for the EPA? Two years away from existing. TypeScript was a baby. AWS was around, but "cloud architecture" was not something undergrads did. The entire modern JavaScript ecosystem (the bundlers, the frameworks, the tooling) post-dates my degree.

And I want to name the feeling in this room right now, because I remember it. It feels like you're studying for a test where the questions change after you sit down. You're grinding through coursework, you're learning whatever framework the internship postings demand or some influencer shouts will make you 100% employable, and somewhere in the back of your mind there's a voice saying: "this will all be obsolete before I've finished paying for it".

That voice is right, by the way. That's the part nobody tells you. The voice is correct about the facts.

It's just wrong about what the facts mean.

Because here's what the half-life framing misses: it treats knowledge like inventory. Stuff on a shelf. Shelf-stable for a while, then expired, then thrown out. And if knowledge were inventory, this field would be a terrible deal — you'd be a warehouse with a permanent spoilage problem.

But knowledge isn't inventory. It's more like, and I promise this is the only finance metaphor in the talk, I work at a credit union now, it's mandatory, it's more like compound interest. Each thing you learn changes the rate at which you learn the next thing. The individual deposit can expire. The compounding doesn't.

I'm not going to argue that abstractly. I'm going to show you. Three stories from my own career: a dead app, a strange sequence of industries, and a very bad Friday in 2025. Each one is a case study in something expiring and something compounding at the same time.

The App That Died Twice #

For most of my career at Sonoma Technology, I worked on air quality software, the tools that tell people whether the air outside is safe to breathe. If you've ever checked an app during California wildfire season to decide whether your kids could play outside: that category of software. That was my job. AirNow was my baby.

One of our products was a multi-tenant mobile application platform, which powered air quality apps for a bunch of different government clients. One codebase, many tenants, real users making real health decisions with it.

When I inherited it, it was built on PhoneGap.

For those who haven't: PhoneGap was one of the first serious "write once, run anywhere" mobile frameworks. Wrap a web app in a native shell, ship to iOS and Android from one codebase. In its day, it was a completely reasonable choice. Adobe owned it. It had momentum.

And then it didn't. The ecosystem shifted under our feet, support wound down, and we had to move. So we migrated the entire platform to Cordova, which was PhoneGap's open-source sibling.

Here's the first thing I want you to notice: that migration was not a technology decision. It was a budget decision. Cordova was the shortest, cheapest path off a dying platform for clients, government clients with mostly fixed price contracts and no appetite for a rewrite. The engineering team could see better destinations on the map. The budget could not reach them. So we made the move we could afford, knowing we'd probably have to move again.

And we did. A few years later, we migrated the whole thing a second time, from Cordova to React Native. That one was technology-driven: the ecosystem had clearly consolidated, the talent pool was in React, the tooling was better, and this time the budget and the technology finally pointed the same direction.

Same app. Three stacks. Two funerals.

Now, let's look at the accounting. What expired, and what compounded?

Everything I knew about PhoneGap specifically: worthless. Gone. The plugin quirks, the build configuration incantations, the workarounds? All of it is trivia now. If knowledge were inventory, those years were spoilage.

But here's what the first migration left behind: I learned how migrations work. How to inventory a codebase's actual dependencies versus its assumed ones. How to build a compatibility layer so you can move incrementally instead of big-bang rewriting. How to sequence the move so the app keeps shipping the whole time. All because our users didn't stop needing air quality data while we redecorated. How to explain to a client, in their language, why this invisible engineering work deserved a line in the budget.

None of that is PhoneGap knowledge. All of that came from the PhoneGap work.

So when the second migration came, Cordova to React Native, a much bigger technical leap, it was faster and cheaper than the first, smaller one. Not because the technology was easier. Because the migration skill had survived the death of the framework it was learned in. I'd paid the tuition once. The second course was discounted.

That's the pattern this whole talk is about, in miniature. The framework knowledge had a half-life of a few years. The meta-knowledge, the "how to move a living system from one foundation to another without dropping it", that has no expiration date I've found yet. I will be using it for the rest of my career, on stacks that don't exist yet.

And one more lesson from this story, because it's the one that surprises students most: neither migration happened for the reason a textbook would predict. One was budget. One was ecosystem gravity. In school, technology choices are presented as technical questions with technical answers. In industry, they are business questions wearing technical costumes. Learning to see the costume, that also compounds, thankfully.

So that's expiration and compounding within one product. Now let's zoom out. Because the same thing happens at the level of entire industries.

The Skills That Crossed Industries #

Here is my resume as a trivia question. What do these three things have in common: recovering data from dead hard drives, wildfire smoke maps, and your checking account?

The answer is: me. And on the surface, absolutely nothing else aside from generalities.

My first real job was at DriveSavers. When your drive dies with your dissertation on it, or a company's server dies with their books on it, and every normal tool says "unrecoverable", it came to a lab like ours. I was on the R&D side, writing the specialized tools. Low-level work. C, C++, Python, Bash. Filesystems, encrypted volumes, BitLocker, FileVault. We built repair protocols for corrupted encrypted volumes that raised recovery rates on those drives by something like forty-five percent. We built ransomware recovery tooling right as ransomware was becoming an epidemic.

Then I moved to Sonoma Technology, wholly within the environmental sciences field. EPA contracts. The AirNow app redesign. Smoke Sense (one of the EPA's flagship citizen-science apps). Completely different world: mobile frameworks, Java backends, public-sector clients, wildfire seasons setting the deadlines.

And now I'm at Redwood Credit Union. Finance. Regulated financial systems. Third industry, third universe.

Three domains with no surface overlap. So the question is: when I walked from one to the next, what actually came with me?

Because here's the honest part first, the expiration side of the ledger. My deep knowledge of drive geometry and filesystem internals? Banking does not care. My encyclopedic understanding of EPA data standards and air quality indices? The credit union has never once asked. Domain knowledge, the moment you leave the domain, converts to trivia at midnight like a pumpkin.

But watch what did transfer.

Systems thinking. Data recovery is forensic systems thinking, where you're handed a broken black box and you have to reconstruct what it was doing from the wreckage. That exact muscle is what let me walk into decades-old government codebases at Sonoma Tech, parts of which were undocumented, the original authors long gone, and read them like a crime scene.

Security instincts. At DriveSavers I spent years on the defense-and-recovery side of encryption: BitLocker, FileVault, ransomware. At Sonoma Technology, when we had a company-wide cybersecurity incident, I ended up helping lead the migration of on-premises systems to AWS and rewriting security policy (hold that story, it's coming back in a minute). And now I'm in an industry where security and compliance are the water we swim in. That's one instinct, deposited in 2014, still compounding in 2026 across three industries.

Working under real constraints. Data recovery taught me to ship when failure wasn't an option and the hardware was literally dying on the bench. Government contracting taught me to ship inside fixed budgets and procurement rules. Those constraint muscles transferred directly into each other and now into banking regulation.

Here's the model I want to give you for this, because "transferable skills" is the phrase on every career-services poster and it's too vague to use. Think of it this way instead: domain knowledge expires when you leave the domain, but the abstractions you built from it travel with you.

Every domain forces you to build abstractions to survive it. Data recovery forced me to build "how do I reason about a system I can't fully observe." The EPA work forced me to build "how do I keep a system trustworthy when the public depends on it." You throw away the domain. You keep the abstraction. That's the refactoring! The exact same operation you'd do to code. Extract the general function; discard the specific call site.

Which means (and this is the sentence I'd put on a poster in the unlikely event that career services asked me): no experience is wasted; it just gets refactored.

The weird job counts. The industry you don't stay in counts. The internship in a technology that dies. I did mine partly on BlackBerry and Windows Phone banking apps, both platforms dead, and it still counts, because it's where I first learned what shipping to real users felt like.

Forced Adaptation #

In May of 2025, after six and a half years, my time at Sonoma Technology ended. Federal contract funding was cancelled, and the work I did went with it. I was laid off.

I want to be candid about this section, because it's the part of a career nobody puts in a colloquium talk, and it's the part you most need to hear. Some of you will do everything right. Everything! A good degree, good skills, good performance reviews (I got an Employee of the Quarter award at STI), and you will still, at some point, lose a job for reasons that have nothing to do with you. A funding line in a budget document you'll never see. A market shift. A pandemic. It is a when for most careers, not an if.

So the useful question isn't "how do I make sure it never happens." You can't. The useful question is: what determines how hard you land?

Everything I'd been talking about since I finished writing on the board: that's what. The compounding is your parachute.

Think about what the job search actually tests. It doesn't test your depth in the stack you just left, because the next employer probably runs a different one. It tests the breadth. It tests how fast you can get productive in their world. Every paradigm you've touched, every domain abstraction you've kept, every migration you've survived, that's the material the parachute is sewn from. You aren't packing it during the fall. You packed it, or didn't, over the preceding decade.

There's a distinction I want to name here, because it organizes everything: planned adaptation versus forced adaptation. Planned adaptation is the migrations, the new frameworks, the side projects. That's change you schedule. Forced adaptation is the security incident, the funding cancellation, the layoff, that's change that schedules you. Here's the relationship between them: planned adaptation is training for forced adaptation. Every voluntary rep makes the involuntary one survivable. The team that has migrated twice on purpose handles the emergency migration. The engineer who has changed stacks by choice handles changing them by necessity.

And the story has an ending, or rather a beginning. In September 2025 I started at Redwood Credit Union. New industry, new stack, new regulatory universe. Some days things are easy-peasy. Other days, they aren't.

And here's the punchline that ties it back to everything: this transition, into the most heavily regulated, most unfamiliar industry of my career, has been the cheapest one yet. Not the easiest emotionally. But the cheapest in learning cost. Because it's the seventh-language problem. My second technology transition cost me enormous effort. My seventh cost me a fraction of that, because at this point I'm not learning stacks. I'm simply pattern-matching to stacks I already know.

Fun fact, actually: my very first internship, back in 2012, was on white-label mobile banking apps. Fourteen years and two industries later, the wheel came all the way around. Nothing wasted. Refactored.

So: three stories. A dead app that taught living skills. Dead domains that left living abstractions. And a career interruption that the accumulated compounding turned from a catastrophe into a transition. Now I owe you the mechanism. Why does temporary knowledge compound? Let's zoom all the way out.

Why Temporary Knowledge Compounds #

Everything I've shown you reduces to three mechanisms. This is the intellectual core of the talk.

Mechanism one: learning transfer. Your seventh language is nearly free.

When you learn your first programming language, you're learning two things at once: the language, and programming. That's why it's brutal. Your second language is easier because programming came with you. By the seventh, something better happens: you stop learning languages and start recognizing them. Rust's ownership model? That's the discipline C++ wanted from me and couldn't enforce. React's component model? I'd seen the shape in Qt widgets years earlier. Every paradigm you genuinely absorb becomes a template you match against forever after.

Here's the practical consequence, and it's the single most actionable idea in this talk: this means breadth of paradigms beats depth in the trendy thing. Depth in this year's hot framework is a depreciating asset. Your fifth paradigm, functional after object-oriented after procedural after declarative, is an appreciating one, because it improves your exchange rate on every future technology, including all the ones that don't exist yet.

Mechanism two: the durable substrate. Some knowledge just… doesn't expire.

Remember I said I graduated in 2013 and almost nothing I use today existed in my coursework? Time to keep my promise about the fundamentals. Because there's an exception to that statement, and the exception is the entire point.

The courses that felt least practical (theory of computation, operating systems, computer architecture, algorithms, data structures), are precisely the ones that haven't aged a day. Not one hour of them has expired. When I was doing data recovery, that was operating systems and architecture, live and unplugged. When I debug React Native performance, that's data structures and memory models. When I evaluate some new framework's grand claims, theory of computation tells me which claims are physically impossible.

Here's the image: the fundamentals are the denominator. Every new technology that comes along gets divided by what you already understand underneath it. A strong denominator makes every numerator smaller. That new framework is a three-month mountain to someone without the substrate and a two-week hill to someone with it, and that ratio holds for every framework, forever. That's not a one-time payoff. That's a permanent discount rate on the future.

Mechanism three: meta-skills. The residue of dead technology.

This is the layer the first two mechanisms don't cover, the skills that aren't about any technology, but that you can only acquire through technologies. Migration judgment: knowing when to move, when to wait, how to sequence it. The ability to drop into an unfamiliar codebase and orient in days instead of months. The instinct for whether a technology decision in front of you is actually a budget decision in costume. Knowing what a dying ecosystem smells like early enough to plan your exit. I promise you, after PhoneGap and ColdFusion, I can smell it.

You cannot learn these from a course, because they aren't knowledge. They're residue. Every framework I listed in the graveyard at the start deposited some. The framework rots; the residue is what's left in the pan; the residue is the valuable part.

So assemble the full model. Any given technology you learn has three components:

1. The perishable surface: syntax, tooling, trivia, gone in five years
2. The transferable paradigm which joins your pattern library permanently
3. The meta-skill residue: which compounds across your whole career

The half-life anxiety comes from staring at the first component. The entire case for this field comes from the other two.

Knowledge is temporary. Learning compounds. Those are not in tension. The temporary knowledge is the mechanism by which the compounding happens, you cannot get the residue without burning through the fuel.

Which brings us to the practical question you should be asking me: "Fine, so what do I do about it, starting today?"

Practical Advice for the Room #

One: optimize for breadth of paradigms, not depth in the trend. When you choose electives, side projects, and internships, ask "does this teach me a kind of thinking I don't have yet?", not "is this what job postings want this quarter?" The postings will want something different by the time it matters. If everything you've built is in one paradigm, your next project should be in another one, even if, especially if, it's uncomfortable. Discomfort is what a new paradigm feels like from the inside.

Two: take the theory courses seriously. I know. They feel like they were designed in 1975, partly because some were. But everything else in the catalog has a half-life, and those courses are the longest-lived assets in this building. They are the denominator. Twelve years out, my operating systems course is still paying and my hottest 2013 framework knowledge is a tombstone. The boring courses are the safe investments. It's exactly as unglamorous as real investing.

Three: always be building something outside of class, preferably in a stack you don't know. The side project is where planned adaptation gets practiced. And this is not just advice for the students; it's a career-long practice. Right now, twelve years in, I'm building a hockey analytics platform on my own time, in Rust and a modern web stack, technologies my day jobs never handed me. The point of the side project is not the product. The point is that it keeps the learning muscle under load, so that when forced adaptation arrives, the rep is familiar.

Four: treat every job's domain as a rotation, not an identity. You are not "an air quality developer" or "a fintech engineer." You are an engineer currently deployed to a domain. Extract its abstractions deliberately. Actually ask yourself, "what is this domain teaching me that generalizes?", and hold the specifics loosely. This also, quietly, is armor: if the domain is a rotation, then losing the domain is not losing yourself. The layoff hurt. It did not delete me, because the domain was never where the value lived.

Five: expect the deprecation notice, and pack the parachute before the jump. Expect the layoff, the cancelled funding, the framework EOL announcement. Not with dread; with the same unbothered planning you'd apply to any other known failure mode and redundancy in a system you were designing. You are the system. Breadth is the redundancy. The side projects are the failover tests. If you've done items one through four, item five is already handled, the parachute is packed as a side effect of how you learned.

Six: treat AI as the newest instance of this entire model, because that's what it is. I use AI tooling every day now, and I can tell you two things about it with confidence. First: the specific tools I'm using will join the graveyard slide, probably faster than anything currently on it. Learn them anyway. Second, and this is the important one, look at which layer AI consumes fastest. It's the top one. The perishable surface. Syntax, boilerplate, tooling trivia. The exact the layer I told you a few minutes ago was already the depreciating asset on a five-year cycle. AI didn't introduce a new kind of loss. It accelerated the layer that was always expiring. Honestly, in doing so, it repriced the other two layers upward. Judgment about what to build. Taste for when generated code is wrong. Reading a system and knowing what matters. The substrate and the residue are now most of the job description. AI didn't break the model in this talk. So far, it's the strongest evidence for it.

Learn It Anyway #

Here's that list again: PhoneGap, BlackBerry, Windows Phone, MFC, ColdFusion, jQuery.

At the start of this talk, I told you this was a graveyard, and I stand by that. Everything on the board is dead.

I would learn every one of them again.

Not out of nostalgia. Out of accounting. PhoneGap taught me how to migrate living systems, and I've used that ever since. The dead phone platforms taught me what shipping to real users costs. The first lesson, still true. Even ColdFusion taught me… patience.

Every stone in that graveyard paid for something I still own. The knowledge was the tuition. The compounding is the degree.

So here is the reframe I want you to walk out with. You are not in the business of accumulating tools. Tools are temporary. Every single one, including whatever you're in love with right now, including whatever replaces it. You are in the business of compounding the ability to pick up the next tool. That ability is the asset. That ability is you. Everything else is fuel, and fuel is supposed to burn.

Nothing here will last. Learn it anyway, because the learning is the only part that was ever going to last, and it's the part nobody can deprecate, defund, or lay off.

One last thing, and then I'll take questions.

The field you are about to enter will be unrecognizable in ten years. I can say that with total confidence, because it has been true of every ten-year window since the field existed — and this one has AI in it, moving faster than any window I've lived through. AI is consuming the perishable layer first. It was always the perishable layer. What it cannot consume is the part of you that compounds.

You could hear that as a threat. Most people outside this room would.

But if you've followed the argument tonight, you know it's the best news in this talk. A field that never changed would spend down your knowledge and give nothing back. A field that constantly changes pays compound interest on every single thing you've ever learned. Forever. For as long as you keep making deposits.

You've picked the right field. Now go learn something that won't last.

Thank you.