Ask most engineers what they do and you’ll get a list: “I’m a React developer,” “I do Go,” “I’m a Python person.” I understand the instinct - it’s legible, it fits on a CV - but I’ve never worked that way, and I think the list is the wrong unit.
Tools are downstream of problems
I don’t start from “what do I know.” I start from “what does this problem need.” If the answer is a language or a framework I haven’t used in a while, I learn it and use it. The cost of picking up a tool on demand is small and getting smaller. The cost of forcing every problem into the one hammer you own is enormous, and it compounds.
This isn’t a claim that fundamentals don’t matter - they matter more than anything. It’s the opposite. Because I understand how runtimes, systems, protocols, and data actually behave, a new framework is mostly new vocabulary for ideas I already hold. The surface changes; the shape underneath rarely does.
What actually transfers
The things worth being good at aren’t tied to a stack:
- Decomposition - turning a vague ask into parts you can reason about.
- Judgment - knowing which trade-off is acceptable here, and which one will hurt in six months.
- Debugging from first principles - following evidence instead of guessing.
- Communication - making the plan and the risk legible to other people.
None of those show up in a tools list, and all of them are why teams call certain people when something is genuinely on fire.
The reliability angle
Adaptability is really a promise about reliability. It says: whatever the problem turns out to be, I’ll meet it - I won’t be stuck waiting for it to look like something familiar. In a field that reinvents its tooling every couple of years, that’s the trait I’d bet a career on. I have.
So no, I won’t tell you I’m a “TypeScript developer.” I’ll tell you that if you hand me a hard problem, it will get solved - and we’ll figure out the right tools together.