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.
With discouraging regularity I do the following:
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.
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.
Next up, tickets with lengthy descriptions. Whenever I'm met with one, my brain works against itself. Usually, one of two things happens:
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.
Which leads us to the final problem: neglecting to properly test everything. There are two aspects to this:
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.
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.