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.
You must log in or register to comment.
Taking amphetamines improves this ability and can fix your issue. But the reason, is because you don’t enjoy this as much as writing code. You enjoying what you do gives you executive power and control over what you focus on, and getting more money is not something that allows you to overcome this, if it’s not stimulating, it’s not as easy for you to do it. This comment is sponsored by by amphetamine.
Jk but I took the route of doing what I love and damn the money. I have to use what dopamine reserves and energy I have on other things in life, household and stuff, and if both drain me I am not as capable as if I adjust my priorities. And I have kids so it’s not hard to choose really. I still count this as a blessing, since when I do stuff I love and they don’t bore me, I can enjoy hyper focus and productivity, and then have energy for life too
I feel this as a mid level dev of 3 years lmao. Maybe straight up ask your supervisors for feedback but im sure some of your thoughts are imposter syndrome rather than genuine poor performance.
If you’re working on a legacy codebase it might even be worth using that knowledge to lobby for technical debt sprints to actually deal with the issues you’re running into. I don’t believe for a second that it’s a problem unique to yourself (though some are weirdly adept at it!)
Good luck pal, it’s a pain for sure
Dev with 18-20 years of experience. I was originally diagnosed in the 90s. Stopped taking meds (Atomoxetine) recently because I hated how they altered my mood.
It’s not just you. Your colleagues probably have the same struggle but it just hasn’t been talked about yet. Any time I’ve brought up a gripe about something, I’ve always had colleagues chime in and agree. Any time I have to traverse complex code like that, I have to have like 5 panes open in VSCode and sometimes I have to take rough notes, or diagram it out.
I’m an admin not a dev, but when writing complex scripts, I found using a whiteboard essential to lay out high level workflows.
Skim the book, “working effectively with legacy code”. In a nutshell, you write characterization tests around the module or method, then do safe IDE based refactorings, then do some slightly more significant refactorings. After that the code should make enough sense for you to make changes if you need to.
It is as much in art as a science. The important thing is that as you are doing refactorings, the main one you do is to extract methods, and give the methods clear names that say what they are doing. You should be left with a top-level method that reads like a narrative of what the whole thing does.
Medication helps me quite a bit. I am also using Atomoxetine. The effect is much more subtle than stimulants, but I think just as powerful in the long run.
I have ADHD and in software engineering. I was also diagnosed recently… around a year ago. Disclaimer: I have around 20 years of experience.
Since I take my medicine I notice that I am way more precise than before and that I am not rushing things anymore. It’s absolutely insane how many sloppy mistakes I made before and how much my code quality improved overall. I am now deeply ashamed how much of a pain in the ass for my colleagues I must have been before :p
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.
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 :)
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.
I personally doubt many people are good at this, ADHD or not. Anyway, logging is the best way for me to “see” what’s going on. If you can output the name of the functions when they are called, you can see the order of what’s happening. Then, hone in on certain areas and add more landmark output statements to show major steps and intermediate results until you locate the problem.
Meds can help the focus required to stick with this tedious process. Logging is a great tool, and even better if you take the time to make it configurable.
I avoid adding logs because after I’m done, I will have to remove them otherwise my PRs will be very big depending on how many files I have to update. I instead track the call hierarchy of the function I am studying using a feature in the IDE. It basically creates a tree of all functions called by a function, which helps me track how deep I am and how I got to where I am currently.
I should probably resume my medication though.
That’s cool, is it visual studio? I guess it depends on the system, but if you have good log files, you or anyone can troubleshoot problems without even looking at the code.
No, IntelliJ IDEA. I do add a lot of logs in my own code though.
I’m a fairly early career dev, my job doesn’t really give me a lot of opportunity to write new code, instead I spend most of my time updating other people’s code, much of which is a legacy rat’s nest. Most of my time on a given story is spent trying to understand the code I’m given, and as I’m reading it I often feel like my eyes start drifting apart, it’s really hard to focus on it and understand the meaning.
The two most helpful things I’ve found are a) diagramming everything out. For that I have a big white board next to my desk, like 15 scattered notebooks and a tablet for onenote. b) my medication.
I was put on Ritalin about a year and a half ago, and (when I remember to take it) the difference is night and day. I wouldn’t say the medication makes the work easier, but it does make me feel motivated to do it and be less distracted even though it’s not work I necessarily want to be doing.
I do feel I should mention since you mentioned having some anxiety issues on other medication that I can end up with the save issue, but I’ve noticed that it only happens if I didn’t eat before taking it, or take it too late in the day to where it’s still fully in effect after I’m done working.
I also absolutely feel you on wanting to refactor everything that doesn’t make sense - it would make life so much easier, but I’m not allowed to do it -_-.
For me, I’ll hop onto a new git branch and start renaming functions and variables to what they actually do.
I might drag some blocks of code out into new functions, just a real rough refactor to get both the flow and my understanding of each block in place.
Big if conditions get their own function, named what the intent is.
I work in Xcode, so we can add extra context to breakpoints. I recently discovered the bookmarks that are built in, and you can annotate them too!
Make a change, start from the top and make sure it reads ok and still makes sense.
It’s eating an elephant on repeat.
Yeah, I use bookmarks and mnemonic bookmarks as well.
Creating a rough git branch is a good idea though, I should do that. Currently, I try not to modify the code too much when studying so that the code because I would later have to revert them back otherwise it would confuse the PR reviewers if there are too many formatting changes not relevant to required changes.
Hi, I am a newbie coder who works on open source projects as a hobby. I usually take notes or draw diagrams of how do the things work.
I have a suspicion that a lot of people, when faced with this problem, just say “Sure, looks good to me. It’s legacy, so it’s been working forever,” and carry on with their day.
But - I could be mistaken.
Until you have to fix some bug some dude introduced seven years ago and is no longer working at the company.
I don’t work in software, but networking, where I often have to work in CLI for configurations on multiple devices simultaneously. What I’ve been taught, and what’s worked for me, is drawing logical diagrams by hand with pen and paper when I’m working in a system that I think has the complexity level to get lost in. I don’t know for sure how well that will translate to software in general unfortunately.
Where that line is varies person to person, so you might only do it for those weird legacy systems. That’s usually how it is for me. This is how I best understand things in general. Laying them out physically in front of me and writing it all by hand in the format that I Intuit really helps me keep track of exactly where I’m working on what
I tried doing that, except instead of drawing diagrams of the flow of execution, I write down a gist of what I understood after reading a couple of lines. It’s still pretty hard to do because interpreting what something does is hindered by things like function or variable names often don’t always align with their actual purpose or even not adequately descriptive either. I often find myself muttering “Why the fuck is this written this way.”
I guess legacy code is the bane of everyone with ADHD.
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?
I am in a similar boat in career. I lead a small team of data engineers and do more code review now than code writing. For me, yes the meds help. They keep the tracks for my train of thought from disappearing. It stops my brain from having the context switching problems. The brain fog clears and I can actually think straight.
I’m on methylphenidate (36mg ER), but different meds work for different brains. Your experience may vary. Caffeine also affects us differently, helping us focus instead of keeping us hyper. I’ve heard it also helps convey some of the meds for more effective delivery.
I find note taking along the way with AI-assisted code summaries help too, but those don’t help my context switching difficulty.
Edit: I’d also add, schedule management REALLY helps. Avoid 30 minute back to back meetings with different themes if possible. Give your brain downtime after a meeting to chill and think. After 3-4 meetings of different concepts, my brain can’t handle anything, even with meds. This causes burnout more quickly than anything I experience.
I already gave feedback to my manager that we were having too many meetings on the same day, so now they are spread evenly over the week. Usually they are not more than 30 mins.
As for caffeine, I think I have developed a tolerance. I have two cups every day and it feels like it hardly helps. I should probably get back on the meds though.
I don’t write code, except for some sql queries used for verification, but do have an understanding of code and have reviewed code with developers when trying to ensure it functions as intended. Have adhd and while I often get praise for being able to understand and convey complex functionality and software concepts, the ever changing code bases is intimidating and keeps me from diving into actual development.
One thing that really helps with reviewing older, especially nested, code is drawing out a simple flowchart. Well, simple unless there is some kind of spaghetti logic that makes it complicated, but frequently just drawing out a loop or indicating when something is changing in the middle of the process can identify where the problem is in a way that is far easier than breakpoints.
I also have some level of aphantasia so I can’t visualize a workflow that I didn’t create, which could be a part of why this works for me, but using it to explain where the code is failing is a lot easier too when you can point at something and say “when the person resets to this step then x, y, and z are reset correctly but when a reviewer resets to that point it is only resetting x and z” because that step needed x, y, and z to be in a particular state.
I don’t exactly draw flow charts, mostly because the nodes don’t make sense to me without context. Instead, I read a few lines, understand what’s going on there and then write down the gist of what I understood. I write these down as bullet points with nesting to track branching code. If still find it pretty cumbersome.
TBH, this wouldn’t have been that big of an issue if the code was commented or documented properly. But then again, who is going to go into code written back in 2018 to document lol.
I also have some level of aphantasia so I can’t visualize a workflow that I didn’t create
I’m sure it’s much more common among developers to not understand another developer’s code.
I do mutter the behaviour of the code to myself when studying like you described.
