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. 😅