Every year there is a list. Learn these fourteen technologies. It is always the same shape: framework, framework, cloud provider, a database, something about Kubernetes, and now something about AI.
The lists are not useless, they are just unranked, which makes them useless in practice. You have maybe a few hundred focused hours this year for deliberate learning. Spending them evenly across fourteen things gets you fourteen shallow familiarities and no leverage.
Here is what I would actually spend them on, in order, with reasoning. I build production SaaS full stack, so this is biased toward people doing the same thing rather than toward interviews.
1. Reading code faster than you write it
Start here because it is now the bottleneck.
Whatever you are producing, you are producing more of it than you were two years ago, and most of it needs review before it is safe. The engineers who are actually fast are fast at reading. They open an unfamiliar diff, find the one line that matters, and move on.
How to practise deliberately: take a pull request in an area of your codebase you do not own. Before reading the description, read the diff and write down what you think it does and what you think will break. Then read the description. The gap between your guess and reality is your reading skill, and it closes with repetition.
This is unglamorous and there is no certificate for it. It compounds harder than anything else on this list.
2. Data modelling
The single highest-leverage thing a full stack developer does is decide what the tables are.
Get it right and features are small. Get it wrong and every feature is a negotiation with your own schema, forever, because by then there is data in production and the migration is a project.
What to actually learn: normalisation well enough to know when to break it. What a foreign key buys you. Why nullable columns are a liability, and how to design so that invalid states cannot be stored rather than merely rejected. Indexes: what they cost on write, what they buy on read. How to read a query plan, which is the skill that separates "the database is slow" from "this query is missing an index on a column with a million rows".
Most performance problems I have been handed were data-model problems presenting as frontend problems.
3. Types as design, not as decoration
Most TypeScript in the wild is annotation. The type describes what the value happens to be. That catches typos.
The next level is using types to make wrong states impossible to write. A discriminated union instead of an object with five optional fields where only certain combinations are legal. A branded type so a UserId cannot be passed where an OrgId goes. Narrow function signatures that accept exactly what they need rather than the whole entity.
This matters more now, not less, because a type error is feedback that arrives without you reading anything. When a large share of code arrives pre-written, the checks that run automatically are the ones doing the work.
4. One backend runtime, properly
Not three superficially. One, down to the parts that bite.
For Node: the event loop, what actually blocks it, streams and back-pressure, how connection pooling works and what happens when the pool is exhausted, why your async function's error vanished. For Postgres alongside it: transactions and isolation levels, what a deadlock looks like in the logs, connection limits.
The reason to go deep on one is that the hard-won knowledge transfers. Once you have genuinely understood back-pressure in one runtime you recognise it everywhere. Fourteen shallow familiarities transfer nothing.
5. Working with AI tooling as an engineering practice
Not prompt tricks. The workflow around it.
The parts worth learning: writing a specification precise enough that the result is checkable. Scoping a task so the diff is reviewable instead of a thousand lines you will rubber-stamp. Building the verification loop first, so tests and types tell you it is done. Knowing which tasks to delegate and which to keep, which mostly reduces to whether you can define what correct looks like.
Two specific things with real payoff: Skills, for turning a prompt you have retyped ten times into something reusable, and MCP, for giving the tool real access to your systems instead of pasting context by hand. Both are boring infrastructure and both compound.
The meta-skill is knowing when not to use it. A five-line change you understand completely is faster by hand than a round trip.
6. Observability
You cannot fix what you cannot see, and in production you cannot reproduce.
Structured logs with a request id you can actually trace. An error tracker wired up before you need it. One dashboard with the four numbers that tell you whether the thing is healthy. Enough tracing to answer "which call in this request was slow".
The bar is lower than it sounds. Most teams have none of this and debug by guessing.
7. Performance, measured
The skill is not "make it fast", it is "know what is slow".
Learn the profiler in your runtime. Learn to read a flame graph. Learn Core Web Vitals well enough to know which one your change moves and which one it does not. Learn what the network tab is telling you about waterfalls.
Most performance work I see is people optimising the part they find interesting. Measuring first is the entire discipline.
What I would not spend this year on
Being wrong about what to skip is as expensive as being wrong about what to learn, so I will be specific.
A second frontend framework. If you know React well, learning Vue to the same depth buys you very little. Depth in one beats breadth across three.
Kubernetes, unless you are paid to operate it. Enormous surface area, almost no application of it if you deploy to a platform. Learn containers. Stop there until someone hands you a cluster.
Whatever state management library shipped this quarter. The problems are cache invalidation, server state versus client state, and optimistic updates. Those are conceptual. Learn them once and every library is an afternoon.
Certifications. Nobody has asked me about one, ever. Not once in four years.
Following model releases as a practice. There is always a new one. The workflow skills transfer across all of them; the release-note knowledge is stale in a month. Learn the workflow, check in on the landscape quarterly.
The order matters more than the list
If you did nothing from this list except get genuinely good at reading code and designing data models, you would be more useful than an engineer who skimmed all seven.
That is the actual argument. These are ranked by leverage, not novelty, and the top two are the least exciting entries by a wide margin. That is usually how it goes.
If you want the broader case for why the centre of the job moved, the old developer versus new developer piece covers it, and what is worth building with AI covers where I think the actual opportunities are.
- #Full Stack
- #Career
- #React
- #AI
- #Engineering