frontend
Dealing With Tech Stack Regret
Thoughts from the intersection of code, craft, people, and progress.
Every choice has tradeoffs. Here’s how I handle mine.
Every technology choice looks clearer with the benefit of hindsight and several years of release notes. Regret is useful only if it helps the team understand the trade-offs, improve the current system and make the next decision with slightly fewer optimistic assumptions.
The useful question behind “Dealing With Tech Stack Regret” is what changes in the work afterwards. A sound idea should improve a real decision, not only give us a neat phrase for describing it.
This matters because small choices repeat. What feels harmless once can quietly become the normal way of working.
Progress needs room around it
It is tempting to treat progress as a question of effort alone. In practice, energy, confidence, context and timing all shape what we can do. Ignoring those things does not make us rigorous; it makes our conclusions less accurate.
I have become more interested in sustainable habits than heroic bursts. A modest routine that survives a difficult week is more valuable than an ambitious plan that only works when life is unusually cooperative.
Sustainable progress is still progress, and it tends to last longer.
A practical way to start
A few questions help me decide what to do next:
- Does this help the user or mostly impress the team?
- Will the choice still make sense under pressure?
- Can we describe the reason without hiding behind jargon?
None of those questions produces an automatic answer. They do make the trade-offs visible, which is usually the point where a team can stop arguing from instinct and start making a decision together.
There is no prize for making useful work unnecessarily painful. Keep enough space to notice what is working, change what is not, and enjoy some of it.
I do not always manage it perfectly. The aim is to make the better choice easier to recognise the next time it appears.