The Anxious People Who Keep Tech Running
✨ Dev Shorts #15 - short and meaningful
This Friday, I refactored a part of the feature I’m currently working on.
Nothing was broken. Tests were passing. The code did what it was supposed to do.
And still, I changed it.
I’m not entirely sure whether I did it because it genuinely made the system easier to reason about, or because sitting with the existing version made me uneasy. The kind of unease that whispers this might get messy later and nudges you to act before you fully understand why.
That uncertainty stayed with me longer than the refactor itself.
Most anxious people in tech don’t think of themselves as anxious.
They think of themselves as responsible.
They’re the ones who prepare early, read ahead, keep things moving. The ones who notice edge cases before they turn into incidents. The ones who would rather over-deliver than risk being the person who missed something obvious.
From the outside, this looks like competence.
Often, it is competence.
But there’s usually something else running underneath.
In my case, anxiety doesn’t show up as panic or overwhelm.
It shows up as the urge to fix things that aren't quite broken yet.
I feel it most clearly when I’m building something and I hit a moment of ambiguity. A decision without a single correct answer yet. Architecture choices. State boundaries. Where data should live. What’s “good enough” to ship.
Those moments are uncomfortable.
And anxiety is very good at resolving discomfort quickly.
A while ago, I was working on a React feature that involved shared state across multiple parts of the app. Nothing exotic. A mix of server data, UI state, and derived values that several components depended on.
I remember the exact feeling.
This could get messy.
So I moved fast.
I introduced global state earlier than necessary. Centralized things just in case. Added abstractions to cover scenarios that might happen later. The code looked clean. Structured. Thought-through.
It also became harder to reason about.
Simple changes started requiring updates in multiple places. Debugging meant jumping between layers of indirection I'd introduced before I needed them. The feature worked, but it felt heavier than it needed to be.
Nothing was broken.
But something was off.
Looking back, the decision wasn’t driven by clarity.
It was driven by anxiety about future complexity.
I wasn’t solving the problem I had.
I was trying to prevent the discomfort of not knowing yet.
That’s the pattern I keep noticing.
In tech, anxiety often disguises itself as foresight.
It pushes you to anticipate everything, abstract early, and make the system “robust” before it has earned that complexity.
Sometimes that instinct is right.
But sometimes it’s just anxiety trying to eliminate uncertainty by turning it into structure.
The hard part is that both paths look identical in the moment. They both feel like good engineering.
What anxiety really changes is how I relate to decisions.
When it’s in the driver’s seat, I optimize for safety over understanding. For speed over judgment. For closure over learning.
In React terms, it’s the difference between lifting state because multiple components truly need it, and lifting state because I don’t trust myself to refactor later.
Both compile.
Only one stays easy to live with.
This is where the pause keeps re-entering my work. Not as a productivity technique, but as a way to see more clearly.
Pausing lets me ask a different question:
Am I designing this because the system demands it, or because my discomfort does?
Sometimes the answer is still yes, we need this now.
Other times, it’s just that I don’t like leaving things unresolved.
Those two feelings are hard to tell apart in real time.
They’re much easier to see later in the codebase.
I don’t think the goal is to remove anxiety from engineering work.
A lot of what makes people good at this job, caring about edge cases, thinking ahead, taking responsibility, is tightly coupled with it.
The problem isn’t having anxiety.
It’s letting it quietly make decisions on your behalf.
I keep thinking about that refactor from Friday.
The code is cleaner now. At least locally. Fewer components and lines of code. Clearer data flow. Easier to follow when I open the project again.
And still, I don’t have a definitive answer.
Maybe it genuinely made sense.
Maybe it was anxiety smoothing out a future that didn’t exist yet.
Most likely, it was a bit of both.
What I do know is that I notice the question now.
That pause, the moment where I ask why I’m changing something, not just how, is still new. It doesn’t always stop me from refactoring. Sometimes it just slows my hand for a second before I do it anyway.
But even that feels like progress.
I’m not trying to eliminate anxiety from my work.
I’m trying to make it visible enough that it doesn’t quietly become the system.
Some weeks, that looks like restraint.
Other weeks, it still looks like a refactor on a Friday afternoon.
I still can’t say I know the difference yet.
Until next time,
Stefania
Articles from the ♻️ Knowledge seeks community 🫶 collection: https://stefsdevnotes.substack.com/t/knowledgeseekscommunity
Articles from the ✨ Dev Shorts collection:
https://stefsdevnotes.substack.com/t/frontendshorts
Articles from 🚀 The Future of API Design series:
https://stefsdevnotes.substack.com/t/futureofapidesign
👋 Get in touch
Feel free to reach out to me, here, on Substack or on LinkedIn.
I often feel the urge to refactor working code just because I anticipate an edge case, but this leads to overthinking and, as you mentioned, anxiety. Bugs still need to be solved before they appear and only experience and a solid framework can help you pick which one to work on.