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.
Hello there, I’m a senior level dev former manager specialized in database shit.
It can absolutely be difficult to trace complex misleading function calls but part of the emphasis in coding should be readability and expressiveness (personally my opinion is that the highest cost in software development is maintenance and difficult to comprehend code multiplies this cost). If something is so complicated that, while it’s being written, it can’t be comprehended then that’d be a huge red flag for me and I’d likely leave comments on the review asking for the code to be better labeled (either better variable/function names, comments, clearer division of class/module responsibility) and refactored. This may not be possible pushback to give in your organization (which would be a big company red flag) but if you have difficulty comprehending it now you’ll have a lot of difficulty in the middle of an incident.
For me personally, I “trust” code labeling to help minimize the scope I need to keep in my head at any given time. If there’s a call out to
saveFileToS3()I won’t inspect it now, I’ll just trust it does what it says on the tin and keep my scope limited to the current change set to comprehend that. Later on in the review when I reach the definition ofsaveFileToS3()if it does anything sneaky, doesn’t do anything necessary to that logical operation (like maybe the file is initially marked private and a second call is needed to mark the file as accessible) then I’ll flag that. Code factorization is a tool for clarity and you should rely on and reinforce it - and if you are trusting ot you should verify that.It sorta sounds like your company may be drastically underinvesting in code maintenance (everyone under invests but there is a reasonable amount of investment to demand) though, that’s a red flag for me and may mean it’ll be difficult for you to function in that environment.
I agree that maintainability is important but the issue is that the team lacks that level of (professional) maturity. Actually they used to avoid writing design documents until I joined the organization and made everyone start doing it. They would simply see the user story and then get to work on the code. We’re talking about code written back in 2018 by some contractors, getting patched till today until it’s now spaghetti with meatballs and ragu on top.
I am planning a training session on DDD and clean architecture for the team so hopefully they will improve later.
Damn, you sound like me at my company… except I just got fired because I can’t fix code fast enough, and they reject any effort to improve it. 35 years of experience here. In some environments, pointing out problems leads to unemployment.
Someone needs to be the advocate for clean code and how it will reduce incidents and errors - it’s not easy but you can make progress. If you’re that deep in the whole automated tests might be a good focus?