The Memory Dilemma for Tech Workers: Why Trying Harder to Remember Makes You Forget More Easily

We often say technology is fleeting—skip coding for three days and you can confuse yourself.

But what truly makes me anxious is the frustration of knowledge I know I've seen, learned, and even used before, yet when a project needs it, my mind goes blank and I can't even recall the keywords.

At first, I thought I just had a bad memory. So I started building a knowledge base in Notion, taking handwritten notes, drawing mind maps, digging through old code... But I quickly realized that no amount of knowledge can stop "forgetting" from happening, especially for technical points I haven't used in two or three months—they seem as if I'd never encountered them.

It wasn't until recently that I shifted my perspective:

Maybe we're not "unable to remember," but rather we're trying too hard to remember. Technical knowledge isn't a memorization contest; it's a dynamic system that constantly evolves and shifts with context.

What truly matters isn't how much you remember, but— whether you have a mechanism for "intentional forgetting" and "technical version management."

This is the survival strategy I've developed as a backend engineer who has forgotten regular expressions countless times.

01. The Truth About Technical Memory: It's Not Laziness, It's Too Much Useless Stuff

We assume that once we learn something, we should remember it, so we frantically write notes, make summaries, and memorize APIs. But the problem isn't a bad memory—it's that we learn too much, and forgetting is completely normal.

The biggest difference between the tech world and school education is: there's no unified textbook here; knowledge itself is fluid.

Today you study database performance tuning, and two months later the business scenario changes, and the entire query structure is different.

The CI/CD tool you carefully researched gets replaced by a new solution three months later.

The YAML pipeline syntax you spent an entire afternoon studying— if you don't touch it for six months, reopening it feels like you never wrote it.

And this is not your fault at all.

Neuroscience also tells us:

The human brain doesn't "permanently store" information. It's better at handling frequently used knowledge and clearly structured meaning, and the rest gets actively cleared to reduce interference.

So instead of berating yourself for not remembering, first accept this:

Forgetting in tech is not a bug; it's a feature.

02. What Are the Timeless "Basics" in Tech?

Not all knowledge becomes obsolete. Looking back, what has truly stuck and remained useful falls into three categories:

The first is long-term stable classic fundamentals. Like time complexity, space complexity, HTTP protocol, SQL join principles, sorting algorithms, data structures. These are your "technical muscles"—they won't be eliminated by framework changes.

The second is cross-language, cross-platform universal models and concepts. Such as SOLID principles, high cohesion and low coupling, idempotency, transaction boundaries, lazy loading, rate limiting, cache penetration, idempotent retries, and various architectural design patterns. Whether you're writing backend in Java or doing DevOps, these are almost always applicable.

The third is engineering experience from pitfalls you've personally stepped into. Especially those points where you were truly burned, optimized, reviewed, and summarized.

For example, now when I see database locks, I automatically think: Is there a row lock? → Are there slow queries? → Is there high-concurrency writes? → Should we consider a queue? This is knowledge bought with pain, and it's already connected to the "problem patterns" in your mind.

These three categories are the content worth preserving in a structured way over the long term.

And the knowledge you've only seen in tutorials, haven't deeply understood, and haven't used in a long time— that's what you need to handle with a "technical version management" mechanism.

03. Stop Forcing Memorization: Build Your Technical "Version Management" System

Technology isn't a static list; it's a constantly evolving system.

Yet we often fight dynamic change with static storage:

Storing everything we've learned in Notion, reluctant to delete anything
Notes piling up until they're impossible to navigate
Still debating whether to review a technology we haven't used in two years

The result is "overload anxiety": we don't lack knowledge; we lack clarity on "what's still worth knowing."

I later adopted a method to relieve this pressure—version management for knowledge.

It roughly involves three actions:

1) Proactively label: set "expiration reminders" for knowledge with a lifecycle For example, if I learned a certain GitHub Action trigger mechanism and haven't used it for three months, I'll add a note next to it in my knowledge base: "Last used: 2024.12". If it exceeds six months, I default to considering it "unverified as effective" and stop trying to remember it.

2) Unified entry point: keep knowledge entry points consistent, don't keep moving things around I use Obsidian for my main knowledge base, Jira Pages for team-specific usage, and GitHub Wiki for public standards. I no longer agonize over "where did I write this down?" Instead, I have a rule: certain types of information go in certain places.

3) Intentional forgetting: delete ineffective notes, keep scenario-based prompts I've deleted many API descriptions copied from documentation, leaving only a one-line reminder: "This API has side effects when retried in async jobs—watch out for side effects." This way, when I search for project-related keywords, I can quickly recall the context instead of relying on rote memorization.

The key is: stop trying to "remember" everything. Instead, let your brain only remember "how to find it again."

04. What Growth Really Requires Is a Mechanism for Updating "Cognitive Ability"

Forgetting knowledge isn't scary; what's scary is forgetting how you once understood it.

Now I focus more on: can I reconstruct the way I understood knowledge?

Not just remembering conclusions, but: Why did I learn this in the first place? How did I judge it was useful? What pitfalls did I hit, what validation methods did I use? What logic did I use to decide A was better than B?

This is what truly belongs to you—your "cognitive ability."

For example, a while back we were refactoring a database schema, and I forgot how to write a certain index, but I still remembered:

It was because queries were slow, and I analyzed the explain plan
I found that a field in the WHERE clause wasn't hitting the index
So I added a covering index, but had to balance write performance

These cognitive pathways—even if I forget the index syntax— let me know how to retrace my steps the next time I encounter a similar problem.

So more important than "remembering more" is— building your own problem-diagnosis methods, knowledge-validation approaches, and judgment models.

Conclusion: Forgetting Isn't Scary; What's Scary Is Having No Mechanism to Rebuild

We all forget. I've forgotten regular expressions more times than I can count, and I still do. But I know where to look, which scenario applies, and what pitfalls to expect.

I no longer treat forgetting as failure; instead, I turn it into a signal: either the knowledge is outdated, or you haven't yet found the "memory path" that works for you.

Tech workers don't rely on memory; they rely on a system of:

Being able to judge what foundational knowledge is worth keeping,
Managing ephemeral technology with a mechanism,
Building a cognitive ability to construct your own understanding system.

These three things are how we grow roots in the tech world. May we all forget with ease and learn with peace of mind.