Two significant overarching challenges I’ve had throughout my career are over engineering and analysis paralysis. Simple things can get spun from days to weeks, and occasionally I have gotten so anxious about edge cases and potential scale, reliability, or performance concerns that I deadlock and can’t get anything done. The advice is to not let perfect be the enemy of good. On the other hand, I think overvaluing expediency is bad craftsmanship.

I’ve found it worthwhile to first train yourself or your team to detect thrashing or deadlocks. This can be as simple as leveraging standups to hold each other accountable when it seems we’re lagging, to an individual tool where you set small, achievable goals for the day and regularly check in where you answer the questions “have I made progress towards these goals?” and “will I be able to finish these goals today?” where an answer of no to either question means you have fallen behind or are in danger of it.

When necessary activate a “get back on track” checklist:

- Does the thing holding me up align with the goal and requirements?

- Is there significant risk attached to the concern, e.g. harm to the user or business, jeopardizes the goal or requirements, legal or ethical concerns?

- Am I unable to mitigate the risk with workarounds, guide rails, quarantine, etc?

- Am I unable to iterate on this e.g. mitigate if possible and fully resolve later but before larger release?

- Can a quick pivot be made to address the issue without jeopardizing your deadlines?

If the answer to any is no, either throw it in the backlog or drop it entirely if it does not have tangible value to the user or stakeholder. If yes, reformulate a plan and reset upstream expectations.

I think this is something most people tend to do instinctively and without ceremony, but can be challenging for less experienced developers, perfectionists, stubborn folks, or people with ADHD.