I have been working in the IT industry for the last 13 years and I was diagnosed with ADHD around two years back.

As part of my job, I have to look at a lot of code. It used to be that I used to write a lot of it, but recently since getting promoted, my work now revolves mostly around reviewing the code others wrote or sometimes enhancing someone else’s code.

The problem comes when I come across some extremely convoluted legacy code. For example, like a function hierarchy with 10+ levels of function calls across several hundreds of lines. This causes me some problems understanding what’s going on because it’s nearly impossible for me to follow every branch to understand which part of the code needs fixing. After a while traversing the function calls I often forget how I got there and have to retrace my steps (I use debug breakpoints but it doesn’t help much). I also tend to get distracted with ideas of how to re-implement the whole thing with best practices rather than focus and work on delivering the fix that I am expected to do. This severely hampers my turnaround time and I’m sure my supervisors are frustrated.

What baffles me, however, is that my other colleagues look like they have no problems working on this codebase. So I cannot really blame the badly written code before my supervisors.

So I just wanted to ask anyone here who has ADHD, works in IT/Software Engineering how do you cope with a situation like this? Also, does medication help here?

I used to be on Atomoxetine, but after experiencing a nasty anxiety attack, I stopped about a month ago. Not that I observed any major improvements while I was on it.

PS: Apologies if the context does not make sense to any of you non-IT folks. I can clarify if you ask.

  • deathmetal27@lemmy.worldOPEnglish
    3·
    10 hours ago

    Anyway: What makes the difference for me: taking the time to think about proper solutions. Let some problems rest for a day and reevaluate the things I made the day before, before review, merge or deployments.

    I agree, I do this when I am designing some new module. I tend to write detailed design documents, covering as much behaviour as possible. I then get it reviewed by someone who might have a good understanding of the business process related to the change. This is not very feasible for legacy code because often there is no proper documentation or comments. What I’d prefer in such cases is to implement new modules in a manner where it lies somewhere outside the legacy body of code (different package or module) and expose functions to hook into the legacy code. This way at least the new enhancements follow best practices and don’t become just another patchwork to the increasingly unmaintainable legacy code.

    Back to your original problem: legacy code like that is probably hard for everyone but it makes a difference in what pace (or patience!) you are doing your work. I think medication can help you with that :)

    True. I have been thinking of resuming medication myself.