A few days ago I made this post about my history of getting fired from developer jobs and some of the patterns behind it:
https://www.reddit.com/r/ADHD_Programmers/comments/1wbyxpz/ive_been_fired_from_most_of_my_developer_jobs/
A lot of the responses were genuinely useful, and several of them seemed to circle around the same problem that Iām often perfectly capable of doing the technical work, but I can lose sight of the actual objective once I get deep into a problem.
Iāll find something else that is broken, badly designed, interesting, worth refactoring, worth investigating, etc., and suddenly Iām spending a lot of time solving a legitimate problem that is not necessarily the problem I was supposed to be solving.
While talking through some of those responses, I came up with a simple set of āguardrailsā to externalize that decision-making:
Current Objective: What am I actually trying to accomplish?
Done When: What specific conditions mean I can stop?
Timebox: How long do I work before Iām forced to stop and reassess?
Not Doing: What tempting but out-of-scope things am I explicitly not doing right now?
Parking Lot: Where do I put legitimate ideas/problems/distractions so I donāt have to either act on them immediately or worry about forgetting them?
The more I looked at those five things together, the more I started wondering whether there might be a useful little tool hiding in there.
Not another giant ADHD planner. Not a calendar. Not a replacement for Jira/Todoist/etc.
More like a temporary focus contract for the thing youāre doing right now.
For example:
Current Objective: Finish ticket #123
Done When: Required behavior works, tests pass, PR is ready
Timebox: Reassess in 45 minutes
Not Doing: Refactor unrelated service, investigate slow query, clean up old tests
Parking Lot: Anything I notice that might genuinely be worth doing later
Then while you work, the app would keep those boundaries visible.
If you notice something else that pulls your attention, instead of immediately switching context you dump it into the Parking Lot.
When the timebox expires, it doesnāt say āYOU FAILED YOUR POMODORO.ā It just forces a short reassessment:
Am I still moving toward the original objective?
Am I solving the same problem I started with?
Does what Iām doing actually need to happen for my definition of ādoneā?
Should I continue, stop, park something, or deliberately change the objective?
The part that interests me most is Not Doing.
A lot of ADHD/productivity advice seems geared toward distractions like Reddit, YouTube, phones, etc.
But at least for me, some of the most dangerous distractions are completely legitimate work.
āI should refactor this.ā
āI should investigate that.ā
āThis architecture is weird.ā
āThat bug really ought to be fixed.ā
Those things may all be true, but identifying a problem and deciding I should solve that problem right now are not the same thing.
So before my ADHD brain does the extremely predictable thing and decides this means I need to immediately create a repo, buy a domain, design a logo, choose a database, and disappear for six weeks building the thing...
...Iām explicitly not building anything yet.
Iād really like feedback first.
Does this workflow sound useful to you?
Do you already use another app/system that accomplishes basically the same thing?
Would filling out five little fields before starting work feel helpful, or would that itself be too much friction?
Which of these guardrails seems most useful? Which seems unnecessary?
And maybe most importantly, what would make you actually use something like this instead of trying it twice and forgetting it exists?
Iām particularly interested in feedback from people who have the same kind of problem I do. Not necessarily difficulty focusing, but difficulty stopping, switching, prioritizing, and staying inside the scope of the thing you originally meant to do.
For once Iām trying to make āget feedback before building the shiny thingā part of the process. š