Software Developers With ADHD: Tickets, Code Review and Hyperfocus

You shipped the hardest feature on the team in a single Thursday that you barely remember. You have also had the same two-line pull request sitting in review for nine days because it needs a description, and you still have not updated the ticket. Being a software developer with ADHD often looks exactly like this from the outside: brilliant in bursts, baffling in between.

This post is for the in-between. It covers why the job is shaped the way it is, how to size tickets so they fit the attention you actually have, how to survive stand-ups and chat without losing your day, what to do about the review and documentation debt, why pairing is the body doubling your team already pays for, and how to get through interviews built around puzzles.

Why the job rewards hyperfocus and penalises everything around it

Writing code is one of the few professional activities with a built-in feedback loop measured in seconds. You change a line, you run it, it works or it does not. For many people with ADHD, that loop is the thing that makes hyperfocus possible, and it is why developers with ADHD are often the ones who solve the gnarly bug at 1 a.m.

Everything around the code has the opposite shape. Tickets need updating, which has no feedback. Reviews require reading someone else's code slowly, with no running and no reward. Documentation is writing for a reader who does not exist yet. Stand-ups interrupt the only morning hour you had. Estimates ask you to predict time, which is the ADHD weak spot in its purest form. The job is roughly 40 percent code and 60 percent the other stuff, and performance reviews weigh the 60. Our post on ADHD at work strategies covers the general case; what follows is the developer version.

Tickets: sizing work so a task fits one sitting

A ticket called 'Implement export feature' is a week of vague dread. The same work as six tickets, each finishable in a two-hour block, is six small wins and a visible board. Sizing is the single most useful habit a developer with ADHD can build, and it is one your team will thank you for.

1. Before you start any ticket, split it until every piece is something you could finish between two meetings. 'Add export button', 'write CSV serialiser', 'add endpoint', 'wire button to endpoint', 'write tests', 'update docs'. Make them subtasks if the tool allows, or a checklist in the ticket description.
2. Write the first concrete action at the top of the ticket: the file you will open, the function you will touch. The next time you sit down, there is no re-orientation cost.
3. Leave a 'where I stopped' note at the end of every session, two lines, in the ticket. Your future self, after a weekend, is a different person with no memory of this.
4. Estimate in sittings, not hours. 'Three sittings' is honest. 'Six hours' is fiction that becomes a deadline.
5. Move the ticket on the board the moment the state changes, not at the end of the day. The board is your external working memory, and it only works if it is true.

Stand-ups, Slack and the context-switch tax

A developer's attention is expensive to load and cheap to lose. For many people with ADHD, getting back into a problem after an interruption takes 20 minutes, not 2, and a day with six interruptions is a day with no code in it. The tax is real, and you are allowed to design around it.

• Prepare your stand-up update the evening before, in the ticket's 'where I stopped' note. Read it out. You will not have to remember what you did, and you will not ramble.
• Set chat to do-not-disturb for two fixed blocks a day and tell the team when they are. 'Heads down 9:30 to 11:30 and 2 to 4; ping me with an @ if it is urgent' is a normal thing to say on most teams.
• Batch chat into three check-ins: after stand-up, after lunch, before you log off. Treat the channel like email, not like a phone.
• When you are interrupted mid-problem, write one line in a scratch file before you respond: what you were about to try. That line is the difference between a 2-minute and a 20-minute return.
• Ask for meetings to be clustered. Four meetings spread across the day kill it; the same four stacked between 1 and 3 leave a morning. Our answer on asking for extra breaks at work because of ADHD covers how to frame scheduling requests as accommodations if you want to.

Code review and documentation: the parts that never get done

Review and docs are where developers with ADHD accumulate quiet reputational debt. Nobody notices the PR you reviewed in ten minutes. Everybody notices the one that sat for nine days. The fix is to make both tasks small, scheduled and templated.

• Reviews, incoming: a 25-minute review block every morning before you open your own code. Smallest PR first. If a review will take more than one block, comment 'reviewing, will finish by [time]' so the author is not waiting in silence.
• Reviews, outgoing: keep your PRs under 300 lines. Large PRs sit because reviewers avoid them too. A PR description template (what, why, how to test, screenshots) saved as a snippet means you never stare at the empty box.
• Documentation: write it in the same sitting as the code, before the PR is opened, while the context is loaded. Docs written a week later cost five times as much. Make 'docs updated' a checkbox in your PR template.
• Commit messages: write them as the 'where I stopped' note. They are the one form of documentation you are already forced to do.

Pairing as body doubling that the team already approves of

Body doubling, working alongside another person so that their presence keeps you on task, is one of the most reliable tools many adults with ADHD have. Software teams have a sanctioned version of it with a respectable name. Pair programming, mob sessions and 'can I share my screen while I figure this out' are all body doubling, and they are already in the culture.

Use them on purpose. Pair for the tasks you avoid alone, which is usually the boring ones: the migration, the test suite, the config. Ask to drive when you need to start and to navigate when you need to think. If your team does not pair, a standing 'co-working' video call with one colleague, cameras on, nobody talking, is the same mechanism and takes no process change. Remote developers in Canada, which is a lot of developers, often find this is the single change that makes home-office days workable.

Interviews, take-homes and the coding-puzzle grind, and what to try this week

Technical interviews are built for sustained, uninterrupted practice over weeks, which is not a thing ADHD brains volunteer for. A few things help. Practise in 25-minute blocks on a schedule, not in a six-hour panic the night before; ten problems over two weeks beat forty in one weekend. Say your thinking out loud in live interviews, because narrating is a form of staying on task and interviewers reward it. For take-homes, split the brief into tickets exactly as above, do the first one within an hour of receiving it so the project exists, and submit at 80 percent rather than missing the deadline chasing 100. You can ask for accommodations in interviews, such as extra time or a written brief, and reasonable employers grant them. Our post on careers that align with ADHD strengths explains why the job itself is a reasonable fit; our answer on whether CBT can help with ADHD at work covers the skills side when the systems alone are not enough.

This week: split your current ticket into sittings and write the first concrete action at the top. Set two do-not-disturb blocks and tell the team. Add a PR description template with a docs checkbox. Book one pairing session for the task you have been avoiding longest. Then put a 25-minute review block in tomorrow's calendar, first thing.