Posted on Apr 16

Frameworks come and go; the fundamentals are the real cheat code

#webdev #ai #programming #sharepointframework

Most developers chase tools. the ones who survive the industry learn the systems underneath.

A few weeks ago I was scrolling through developer job listings.

You know the kind.

The ones that look less like a job description and more like a grocery list of frameworks.

React
Next.js
GraphQL
Tailwind
Docker
Kubernetes

And somewhere in the middle of it all you start wondering if the role is actually “software engineer” or “collector of JavaScript ecosystems.”

The funny part is how normal this has become.

Every few months a new framework appears. A blog post goes viral explaining why it fixes everything wrong with the previous framework. Tutorials explode. Courses appear. Half the developer internet starts rebuilding their side projects with the new stack.

Then a year later something else replaces it.

And the cycle starts again.

The strange thing is that underneath all this movement, the core mechanics of software barely change.

Browsers still send HTTP requests.
Servers still process them.
Databases still store data.
Operating systems still manage processes and memory.

Frameworks sit on top of those systems, but they don’t replace them.

Frameworks feel new.
Fundamentals age slowly.

That difference matters more than most developers realize.

I learned this the hard way early in my career.

Back when jQuery plugins were everywhere, I spent weeks learning different libraries for tabs, sliders, and modal windows. It felt productive because I could build UI features quickly.

Then one day something broke.

None of the plugins helped.

The real issue turned out to be a DOM event propagation problem. Once I understood how browser events actually worked, the fix took five minutes.

That moment changed how I looked at programming.

Because it showed me something simple.

The tools were never the real skill.

Understanding the system was.

TL;DR

If you build your career around frameworks, you’ll constantly feel like you’re catching up.

If you build it around fundamentals, new tools start feeling predictable. They’re just different interfaces built on ideas you already understand.

Frameworks rotate.

Fundamentals compound.

The framework trap

At some point the industry quietly changed.

Developers stopped learning how systems work and started learning how tools work. It’s subtle, but the difference changes everything about how people approach programming.

Most developers today begin with a framework tutorial. Something like React or Next.js. Within a few hours you can build something impressive routing, components, styling, maybe even an API.

That accessibility is incredible. Frameworks lowered the barrier to building real products.

But they also created a strange side effect.

A lot of developers now understand framework APIs better than the systems underneath them.

The problem only shows up when something breaks.

Requests start timing out. Pages load slowly. Memory usage climbs. Everything looks correct in the code, yet the application clearly isn’t behaving the way it should.

This is the moment when the abstraction stops helping.

frameworks simplify systems.
They don’t replace them.

The complexity never disappears it just moves deeper into the stack.

I remember running into this during a backend migration.

Our team moved an API from Express.js to Fastify because the benchmarks showed better performance. The migration itself was simple and everything worked perfectly during testing.

Then production traffic arrived.

Requests started timing out and the API became unstable. Naturally we assumed the new framework was the issue, so we spent hours digging through configuration files, middleware, and plugin documentation trying to find the problem.

Nothing looked wrong.

Eventually someone checked the database logs. The real issue turned out to be a misconfigured connection pool in PostgreSQL.

Fixing it took five minutes.

Understanding why it happened took much longer.

That experience changed how I look at frameworks.

They aren’t foundations. They’re interfaces convenient ways to interact with deeper systems like networking, operating systems, and databases.

Once you realize that, every new framework launch feels less revolutionary. It’s just another tool sitting on top of the same underlying ideas.

The tools change.

The fundamentals rarely do.

Why fundamentals quietly win careers

Early in my career I thought the best engineers were the ones who knew the most tools.

They knew every framework.

Every library.

Every trendy stack that appeared on GitHub.

But after working with a few really strong engineers, I noticed something strange.

They didn’t talk about tools very much.

They talked about systems.

One of the best backend engineers I worked with could open almost any codebase and start understanding it within minutes.

Different language.
Different framework.
Different architecture.

Didn’t matter.

He wasn’t memorizing frameworks.

He understood how the system underneath them worked.

Most modern applications are built on a few core ideas that haven’t changed much in decades.

Browsers send HTTP requests.

Servers process them.

Databases store and retrieve data.

And the entire process runs inside an operating system managing processes and memory.

Once you start understanding those layers, frameworks begin to look much less mysterious.

Tools change quickly.
Systems change slowly.

That difference is where experience compounds.

Take something like networking.

Every backend framework whether it’s Express.js, Fastify, or something else entirely ultimately deals with the same request–response model.

A client sends a request.

The server processes it.

A response comes back.

Once you understand how HTTP works, a lot of backend frameworks start looking like different ways to organize the same idea.

The same pattern shows up with databases.

Tools like Prisma or PostgreSQL might look different on the surface, but underneath they still rely on the same concepts queries, indexes, transactions, and data relationships.

Once those fundamentals click, switching tools becomes much easier.

You’re not learning everything again.

You’re just learning a new interface for concepts you already understand.

That’s why experienced engineers often seem to move between stacks effortlessly.

They aren’t starting from zero.

They’re recognizing patterns.

And once you start seeing those patterns too, the entire ecosystem becomes less overwhelming.

The compounding effect of real knowledge

One thing nobody tells you when you start programming is this.

Knowledge doesn’t grow evenly some skills fade quickly others compound for years framework knowledge often belongs in the first category. fundamentals belong in the second.

When you learn a framework, you’re mostly learning its structure.

Where files live.
How routing works.
Which configuration unlocks which feature.

It’s useful knowledge, but it’s very specific to that ecosystem.

Switch to another framework and a lot of that context resets.

Different conventions.
Different folder structure.
Different tooling.

Fundamentals work differently.

They stack.

Understanding one concept suddenly unlocks a dozen technologies.

Take relational databases as an example.

Once you understand indexing, query planning, and transactions, tools like PostgreSQL, MySQL, or ORMs like Prisma all start to feel familiar.

Different syntax same ideas.

The same thing happens with operating systems.

Learn a bit about Linux processes, memory management, and file systems, and suddenly tools like Docker stop feeling mysterious.

Containers aren’t magic.

They’re just clever ways of packaging processes using existing kernel features.

Once you see that layer, the abstraction becomes easier to reason about.

The easiest way to think about this is like a skill tree in a game.

You unlock one core ability and suddenly ten more abilities become available networking helps you understand APIs operating systems help you understand containers databases help you debug backend performance.

One idea unlocks entire parts of the ecosystem.

That’s why experienced developers often learn new stacks much faster than beginners.

They’re not learning everything from scratch.

They’re mapping familiar concepts onto new tools.

The interface changes.

The underlying ideas stay recognizable.

How to learn fundamentals without becoming a theory zombie

Whenever someone says “learn the fundamentals,” a lot of developers imagine the worst possible scenario.

A giant computer science textbook.

Hundreds of pages of algorithms.

Pure theory with zero connection to real projects.

That’s usually where motivation dies.

But learning fundamentals doesn’t mean becoming an academic.

It just means understanding the systems you already use every day.

One of the best ways to do that is surprisingly simple.

Build smaller things not massive apps just tiny systems.

Write a basic HTTP server.

Create a simple CLI tool.

Build a small caching layer.

Even something like a minimal key-value store will teach you more about software systems than dozens of tutorials.

Projects like Build Your Own X are perfect for this kind of exploration. They walk through rebuilding simplified versions of real tools so you can see what’s happening under the hood.

Once you build something yourself, abstractions start making a lot more sense.

Another underrated skill is reading documentation.

Most developers learn primarily through tutorials.

Tutorials are great for getting started, but documentation is where systems reveal how they actually behave.

Reading the docs for something like Node.js or PostgreSQL gives you a much clearer picture of how requests, processes, and queries move through the system.

It’s slower than watching a tutorial.

But the understanding lasts much longer.

And honestly, the fastest teacher in programming hasn’t changed in decades.

Breaking things.

You build something.

It crashes.

You dig through logs, trace the issue, and eventually understand why it happened.

That loop is where fundamentals actually stick.

build. break. debug. repeat.

It’s messy.

But it’s also how most real engineers learn.

The future of dev skills

Lately there’s been a lot of discussion about AI replacing developers.

You’ve probably seen the headlines.

AI writes code now.
Developers will disappear.
Prompt engineers are the future.

The narrative changes every few months, but something interesting is happening underneath all the noise.

AI tools are getting very good at generating code.

Tools like GitHub Copilot and ChatGPT can scaffold APIs, generate functions, and even produce working application structures in seconds.

That’s impressive.

But it doesn’t actually remove the need for understanding systems.

Because the hardest problems in software rarely come from writing code.

They come from understanding how the entire system behaves.

Slow database queries.

Networking bottlenecks.

Caching mistakes.

Infrastructure misconfigurations.

These problems don’t show up as syntax errors.

They appear when real traffic hits a real system.

That’s where fundamentals become valuable again.

Understanding networking helps you diagnose latency.
Understanding databases helps you spot inefficient queries.
Understanding operating systems helps you reason about resource usage.

AI can generate code quickly.

But it still relies on humans to understand the architecture around that code.

AI accelerates coding.
fundamentals guide engineering.

There’s another effect AI will likely have on the ecosystem.

It will make building tools easier.

If developers can generate frameworks faster, we’ll probably see more frameworks, more libraries, and more abstraction layers appear every year.

The ecosystem will move faster.

Not slower.

And that makes fundamentals even more important.

Because when the tool landscape changes rapidly, the developers who adapt best are the ones who understand the layers underneath everything.

The role of developers may shift over time.

Less manual boilerplate.

More system design.

More debugging complex production behavior.

More thinking about architecture.

In other words, the valuable skill becomes system thinking.

Understanding how the pieces fit together because while the tools keep evolving… the underlying systems still follow the same fundamental rules.

Frameworks fade. fundamentals compound.

If you stay in this industry long enough, you start noticing a pattern.

The tools everyone swears by eventually disappear.

The framework that dominated job listings slowly fades away.
The library that powered half the ecosystem stops getting updates.
The “future of development” quietly becomes part of tech history.

Yet somehow the same engineers keep showing up across different stacks.

Different languages.
Different frameworks.
Different companies.

Still productive.

Still adapting.

The reason isn’t that they memorize every new tool.

It’s that they understand the systems underneath those tools.

Networking.
Databases.
Operating systems.

How requests move through a system.
How data flows between components.
How resources behave under load.

Once you understand those layers, new frameworks stop looking intimidating.

They just look like new interfaces built on familiar ideas.

That’s why some engineers seem to jump between stacks effortlessly.

Frontend one year.
Backend the next.

Infrastructure after that.

It’s not because they know every tool.
It’s because they recognize the patterns underneath the tools.

And once you start seeing those patterns too, the ecosystem feels much less chaotic.

The reality is the industry will keep changing.

New frameworks will appear.
New languages will gain popularity.

AI will generate more code than ever before.

But the underlying mechanics of computing evolve much more slowly.

Networking still moves packets.
Databases still organize data.
Operating systems still manage processes and memory.

Those fundamentals stick around for decades.

So learn the tools you need.

Experiment with new frameworks.

Build things and ship projects.

But every once in a while, go one layer deeper.

Trace how a request actually travels through your system.
Understand why a query becomes slow.
Figure out what the operating system is doing behind the scenes.

Because frameworks come and go.

But fundamentals compound.