The concepts that trip up senior engineers when they switch stacks

Kalavathi Bathula — Sun, 06 Sep 2026 16:49:58 +0000

I have spent the last two years mapping how engineering concepts move between technology stacks. Not writing tutorials — mapping. Taking one stack and another and going concept by concept, asking a narrow question each time: does this transfer, and if it doesn't, why not.

Twelve stack pairs so far. Angular to React, Angular to Vue, Node to Spring Boot, SQL to MongoDB, REST to GraphQL, Docker to Kubernetes, AWS to Azure, and a few others. Seventeen core concepts in each.

The thing I did not expect: the hard part is not what engineers don't know. It's what they think they already know.

Four ways a concept travels

Once you look at enough pairs, every concept falls into one of four buckets.

Direct. Same idea, different spelling. Angular's *ngIf and React's {condition && <div/>} are the same thought. An engineer reads it once and moves on. These make up a large chunk of any transition, and they're why senior engineers get frustrated with beginner courses — you're being taught to walk when your legs work fine.

Partial. The idea survives the crossing but the rules change. Component lifecycle exists in Angular and in React, and it means the same thing conceptually — a defined sequence of creation, update and destruction where side effects can run safely. But the shape is completely different. Angular gives you named hooks. React gives you one effect primitive and a dependency array, and expects you to express the same intent through it. You get there, but you can't get there by translating line by line.

New. No equivalent in the stack you came from. Server components. Kubernetes control loops. Aggregation pipelines, if you've only ever written joins. These are honest work. You know you don't know them, so you go and learn them, and the learning is uneventful.

And then the fourth one.

False friends

Linguists have a name for this. A false friend is a word that looks like a word in your language and means something else. Spanish embarazada looks like embarrassed. It means pregnant. People make this mistake once and then never forget it.

Technology stacks are full of these, and they are where experienced engineers write their worst code.

Dependency injection to custom hooks. Both solve the same underlying problem: extract cross-cutting logic so consumers depend on a stable interface instead of reimplementing it. An Angular engineer moving to React sees custom hooks and thinks: this is DI with different syntax. Then they write a hook that behaves like a singleton service and cannot understand why each component has its own copy of the state. Angular services are instances managed by an injector with a defined scope. Hooks are functions that run on every render. The purposes rhyme; the mechanics have nothing in common.

RxJS to React Query. Both orchestrate asynchronous data into something the UI can render. An Angular engineer reaches for React Query expecting a stream primitive they can compose, and finds a cache with a fetch strategy attached. The mental model that produced elegant RxJS pipelines produces awkward React Query code, because the abstraction is not the same abstraction.

SQL joins to MongoDB aggregation. $lookup looks like a join. It is not a join. Engineers who treat it as one write pipelines that work perfectly on a thousand documents and fall over at a million, because they never internalised that the data model was supposed to change too.

Node's event loop to Spring Boot's thread pool. Both handle concurrency. An engineer who learned concurrency through threads carries a mental model of parallel execution into a runtime that has exactly one thread doing the work, and writes something that blocks it.

The pattern is always the same. The concept is familiar enough that you skip the part where you check your assumptions. The failure shows up later, in production, in a form that doesn't obviously trace back to the assumption you made.

Why this matters for how we teach experienced engineers

Almost every learning resource is organised around the destination. Learn React. Learn Kubernetes. Learn Go. They assume you arrive empty.

But nobody with seven years of experience arrives empty. You arrive with a full mental model of how software works, most of which transfers, some of which transfers with modification, and a small dangerous fraction of which will actively mislead you.

The useful question is not "what does React do?" It is: given what I already know, what actually changes?

That is a different question, and it has a different answer for every pair of stacks. An Angular engineer moving to React has a completely different learning path from a Vue engineer moving to React, even though the destination is identical. Nobody teaches it that way, because teaching it that way means doing the mapping work for every pair, and the mapping work is slow and manual.

I have been doing that work anyway. It is why I built SwitchBySkill — a platform that starts from the stack you know and shows you only the delta, with the false friends flagged explicitly rather than left for you to discover in a code review.

What I would ask you

If you have switched stacks recently, I would like to know your false friend. The concept you were sure you understood, that turned out to work differently, that cost you a day or a sprint or an incident.

I am collecting these. Every one I hear about makes the mapping better.

DEV Community: Kalavathi Bathula

The concepts that trip up senior engineers when they switch stacks

Four ways a concept travels

False friends

Why this matters for how we teach experienced engineers

What I would ask you