Coding With ADHD: The Mac Focus Workflow I Use to Actually Ship Code

I sat down at 9 a.m. to fix a one-line bug. By noon I had rewritten a module's error handling, added tests nobody asked for, and — this is the part that stings — not touched the actual bug. It was still open. My brain had found something more interesting than the ticket and hyperfocused straight past the thing I was actually paid to do.

If you write code with an ADHD brain, you know this feeling in both directions. The same head that can lock onto a gnarly bug for six unbroken hours cannot make itself start a boring two-point ticket. The same novelty-hunger that makes you good at architecture and debugging is what pulls you into a refactor you didn't need at 11 a.m. on a Tuesday.

Most "coding with ADHD" advice is generic — take breaks, use Pomodoro, buy headphones. Useful, but it never names the developer-specific ways an ADHD brain goes off the rails. This is the setup I run on my Mac. You can rebuild it with any tools you like; I use Focusmo because it lives in the menu bar and keeps most of it in one place.

Why Coding and ADHD Are a Strange Match

Coding is, weirdly, one of the most ADHD-friendly kinds of work there is. It's novel, it's a puzzle, it gives immediate feedback (the test passes or it doesn't), and it rewards the kind of deep, tunnel-vision hyperfocus that ADHD brains fall into naturally when something is interesting. On the right task, an ADHD developer isn't disadvantaged — they're in their element.

The problem is that every one of those strengths has a shadow:

• Hyperfocus locks you onto the interesting problem, which is often not the assigned one.
• Novelty-seeking makes greenfield work feel electric and maintenance tickets feel impossible to start.
• The dopamine of a passing test trains you to chase quick wins (a satisfying refactor) over slow, ambiguous ones (the vague bug report).
• Deep focus takes 15–20 minutes to build and one Slack ping to shatter — and a codebase you're holding in your head is expensive to reload.

The move isn't to force your brain to focus like a neurotypical developer's — it's to engineer your environment so your brain's defaults point at the right target. First, the traps: you can't guard against what you can't name.

The Developer-Specific Traps

The build-wait rabbit hole

Your build takes 90 seconds. Your CI run takes eight minutes. Your test suite takes long enough that you "just check" one thing while it runs. That gap is the single most reliable on-ramp to distraction in a developer's day, because it's dead time your brain refuses to sit in. You alt-tab to a tab, then a second tab, and the build finishes into an empty chair. Twenty minutes later you resurface.

The fix isn't willpower during the wait — it's making sure the wait has nowhere to leak.

"I'll just refactor this real quick"

This is the one that got me at 9 a.m. You open a file to fix a typo, notice the function next to it is ugly, and hyperfocus does the rest. It feels productive — you're writing good code! — which is exactly why it's dangerous. Hyperfocus aimed at the wrong target burns your best hours on work nobody prioritized while the actual ticket sits untouched. Scope creep, but internal, and invisible until standup.

Ticket-start and PR-review paralysis

A fresh ticket with a vague description, or a 900-line pull request to review, hits the ADHD brain as a wall with no obvious first move — and the brain answers a wall with a freeze. You reread the ticket four times, open the files, close them, and check Slack. It's not laziness; it's the gap between "I should start" and knowing the literal first line of code to type.

Notification hell

Slack, GitHub, email, calendar, the deploy channel. Each ping costs a full context reload, and when the context is a data structure you're juggling in working memory, that reload is brutal. Death by a thousand pings is a real productivity tax, and it's worth putting a number on — our distraction cost calculator does exactly that.

The Mac Focus Workflow

Each of these moves attacks one of the traps above. You don't need all of them at once — start with the two that hit your worst pattern.

1. One ticket, one session, one visible timer

I don't "work on stuff." I start a session: one ticket, one bounded block, one timer running in the menu bar where I can't miss it. The timer gives an otherwise edgeless afternoon a beginning and an end, which is half the battle for a brain that loses track of time inside code.

The key for developers: don't force rigid 25-minute Pomodoros mid-debug. Ripping yourself out of a hard problem at minute 25 is worse than useless. Use a flexible, flow-friendly length and size the block to the task — I break down how in the best Pomodoro timer setup for developers. The rule that matters is simple: no coding block without a visible timer running.

2. Decide the first line of code before you start

Ticket-start paralysis lives in the gap before the first keystroke. So I remove the decision from the frozen moment: before I close a ticket for the day, I write down the literal first action for next time — "write the failing test for the null case," "stub the endpoint signature," "reproduce the bug locally." Not "implement the feature." One concrete, tiny, physical action your brain can actually initiate. Once you're typing, continuing is a completely different and far easier problem than starting cold.

3. Block the escape hatches — especially during the wait

I block my usual flight destinations — Slack, the GitHub notifications tab, Hacker News, X — for the length of a focus session. Not because I lack discipline, but because blocking distractions removes the decision entirely. The build-wait can't leak into a two-hour detour if the tab won't open. You don't have to resist a thing that isn't there.

This is also the single best defense against notification hell: mute the channels at the source for the block, and batch-check them between sessions instead of letting them interrupt mid-flow.

4. A check-in to catch the refactor rabbit hole

The "I'll just refactor this" trap is invisible from the inside — you feel productive right up until you realize the ticket is untouched. The only thing that reliably catches me is an external nudge that fires on a schedule and forces one question: am I on the ticket I said I'd be on?

I use scheduled accountability check-ins for this. Most fire and I dismiss them in two seconds. But every few blocks one catches me three files deep in an unplanned rewrite, and I get to climb out after fifteen minutes instead of surfacing at lunch. It's the closest thing to having a senior dev tap you on the shoulder and ask what you're working on — without needing the senior dev.

5. Let the day log itself

Developers love data about everything except their own time. For years, if you'd asked where my day went, I'd have guessed — and been wildly wrong. So I let the day record itself with automatic, local activity tracking: which apps and repos I was actually in, built into a timeline without me touching anything.

The first week was humbling. The "quick" refactor was three hours. Standup plus the Slack tail was ninety minutes. The bug I swore took twenty minutes took two hours across four interruptions. That's not a guilt trip — it's the raw material for planning against reality. Run your real numbers through our deep work calculator and you'll probably find you get far fewer true deep-work hours per day than you assumed, which is the first step to protecting the ones you have.

6. Capture the shiny idea instead of chasing it

Mid-ticket, your brain will offer you a gift: "oh, we should also fix X." Chasing it is how one ticket becomes six open branches. Capturing it costs three seconds and keeps you on task. I keep a task manager one keystroke away and dump the idea there instead of context-switching to it. Focusmo plugs into the tools developers already live in — Todoist, Things 3, Obsidian, and others — so the capture lands where you'll actually see it later. If you run your notes and tasks out of one vault, the Obsidian-for-ADHD workflow pairs well with this.

Work With Hyperfocus, Not Against It

Here's the thing generic advice gets wrong: the goal isn't to suppress hyperfocus. Hyperfocus is a developer superpower — six hours of unbroken depth on a hard problem is how the best work gets done. The skill is aiming it and bounding it.

Aim it: schedule your hardest, most ambiguous work — the greenfield feature, the nasty concurrency bug — for the window when you naturally drop into depth, and leave code review, standups, and admin for your lower-energy hours. Bound it: put a hard stop on the tunnel, because the same trait that gives you six great hours will also give you a 1 a.m. session that wrecks tomorrow's standup and blurs the line between "shipped it" and "broke it while exhausted." I get into the double-edged nature of this in ADHD hyperfocus: the myths that keep you stuck.

And if you genuinely cannot feel time passing while you're in code — if whole afternoons vanish mid-function — that's time blindness, and it responds to the same fix as everything above: put time outside your head, on a timer and a check-in, so a broken internal clock stops mattering as much. (For the general version, our guide on getting into flow state at work covers the fundamentals.)

A Realistic Coding Day

Putting it together, a good day looks like this:

• Morning peak: hardest ticket first. Session started, timer running, Slack and GitHub notifications blocked, first line of code already decided from last night.
• Build waits: guarded — nowhere to leak, so I stare at the logs or stretch instead of alt-tabbing into oblivion.
• A check-in fires mid-morning: catches me if I've wandered into an unplanned refactor; if I'm on track, I dismiss it and keep going.
• Afternoon dip: PR reviews, code comments, ticket grooming — the low-activation-energy work that doesn't need peak focus.
• End of day: I look at the real timeline, not my memory, and set tomorrow's first line of code before I close the laptop. Then a hard stop.

None of this is about becoming a different kind of developer. It's about building rails so your brain's natural pull — toward the interesting, the novel, the deep — lands on the ticket that's actually due.

The Takeaway

You are not a worse engineer for having ADHD. Your brain runs on interest, novelty, and challenge, and writing software supplies all three in a way few jobs do. The trouble is only that those same drives will happily aim six hours of brilliant focus at the wrong file. So build the guardrails: one ticket per session, a visible timer, a first line of code decided in advance, blocked escape hatches, a check-in to catch the drift, and an honest log of where the time really went. You're not trying to focus harder. You're trying to make the right work the easiest thing to start.

If you want those rails in one place on your Mac — a flexible focus timer, distraction blocking, accountability check-ins, integrations with the task managers you already use, and automatic local tracking so you can finally see your real coding day — try Focusmo. It's a free menu-bar app built for brains that hyperfocus on the wrong thing.