I have a dark secret, one that brings me grief and self-doubt. I make stupid mistakes, regularly. It's embarrassing, especially for a senior engineer, and I know what to blame: ADHD.
It hides the code as I review it, it urges me while I slow down, it makes me certain when I should be doubtful. It affects all aspects of my life in various ways.
Recently I've developed solutions that allow me to make these mistakes less often. It's something that I believe can be helpful to everyone, so let's go on a journey through my head.
Problems and Solutions
With discouraging regularity I do the following:
- create pull requests with debug code I forgot to remove
- implement only part of the requested feature
- fail to test a change after a last-second modification that breaks something
Why? The clue is in the disorder's name: Paying attention is a struggle. You may ask, what's the big deal? Just be more attentive, right? But that doesn't work. You can't throw more attention at a problem when you don't have enough in the first place.
Here's the simple explanation: My brain is a dopamine junkie. When it's not getting a hit, it does everything it can to get one. Let's dive deeper into how this affects my work and what solutions I have developed.
Inaccurately Reviewing My Code
I believe I can speak for most developers when I say that there's something about reading your own code that makes it very challenging. Part of it is its familiarity. Part of it is the inability to distance yourself from it.
But for me, part of the difficulty comes from my brain constantly craving interesting things. It wants the dopamine boost from creating a pull request or marking a task in review. It tricks me into being certain the code in front of my eyes is correct and already properly reviewed, even as I am starting.
While for the most part I've learned to carefully review what I wrote, I have some blind spots when it comes to debugging code. I insert a lot of var_dumps, console.logs and exits when testing things and they tend to sneak into my commits.
The solution here is an unforgiving pre-Commit hook. I put together a simple bash script that warns me when I am about to commit the aforementioned expressions. It checks the staged changes for the occurrence of these keywords.
And while it can't detect subtler changes like || true added to a condition or commented-out code, it's more than enough to prevent the most mortifying mistakes. Besides:
“Perfect is the enemy of good.” (most likely someone before Voltaire)
If you're curious, here's the hook's code.
Reading Objectives Inattentively
Next up, tickets with lengthy descriptions. Whenever I'm met with one, my brain works against itself. Usually, one of two things happens:
- I find the first part that needs to be done, do it, and forget about the rest.
- I skim the whole description, do some of it, forget there were other things.
Either way, I end up with a partially done ticket. Trying to pay more attention doesn't accomplish anything. So instead I came up with a way to reward myself for reading the description carefully: I give my brain the high it desires for doing what I am supposed to do.
All it takes is some paraphrasing. If the ticket is in any way complex or multi-step, I'll take brief notes while reading. That way, I get the dopamine fix while future me has both internalized the objectives and has a handy todo list that can be crossed out. Crossing things out is fun.
Not Thoroughly Testing Everything
Which leads us to the final problem: neglecting to properly test everything. There are two aspects to this:
- I don't test a certain test case because I never thought about it
- I make last-minute tweaks while absolutely certain they will work
Both have the same outcome: They can introduce new bugs. What's curious is that I remember to test, but my brain convinces me that everything has been tested properly so we can proceed to do the fun stuff. It's very difficult to notice this state of mind and pull yourself out of it. There is an easy way out though: Give myself a reason to want to test.
After paraphrasing the description I take a moment to write down test cases as actionable steps. If possible, with checkboxes to tick (because crossing things out is fun). That way, instead of looking forward to close the ticket, my brain is looking forward to do all the points on a list.
The additional benefit is that a QA can later use it as a basis for their own testing and as a way to gauge from which angles the code should also be tested. I will keep updating the list while working on the ticket too.
Closing Thoughts
Like I mentioned near the beginning, all these problems stem mostly from one thing: My brain is a dopamine junkie constantly occupied with getting the next shot. The moment I'm not doing anything interesting, it chases after the next engaging thing. Because of that, many solutions that work for neurotypical people are fruitless as soon as the novelty factor wears off.
For me, dealing with ADHD as a developer has mostly been about recontextualizing boring aspects of my work to provide that dopamine boost.
Sometimes it involves techniques such as the above, other times I go back to the Pomodoro technique or a non-engaging podcast in the background. Finding these solutions has been a long, but ultimately rewarding journey that has made and still makes me a better developer.
