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.

  • stale_cheetos@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    5 hours ago

    I’m a full-stack dev with 8 years experience mostly in startups. I was diagnosed about 5 years ago (at 32 years old), started on methylphenidate and moved to amphetamines 2 years ago. I’ve worked with legacy code very briefly and early on, and that experience is what made me want to seek out startups/new companies. That being said, I still come across convoluted spaghetti code or deeply nested UI components. I feel like it takes me a lot longer than my peers to gain a general understanding of what’s going on, exactly as you describe. I keep a pen and notebook beside my keyboard at all times and in these situations I write/draw the structural heirarchy, logic flow, etc. While it takes me longer, I feel like my standard for “baseline” understanding is much higher and when I reach it, I have more understanding about the code in question than my peers.

    …then I forget it after a week or so 😂

    But really, writing/diagramming things really helps me. If physical writing isn’t your thing you could try something like lucidchart or mermaid diagrams.

  • entropicdrift@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

    Ironically these types of tickets are kinda my ADD superpower. I hyperfocus on understanding the entire flow until I fully understand every possible way the bug could occur, then fix it.

    It’s when I’m trying to plan something from the ground up that the writer’s block hits me and I fall into procrastination and infinite rabbit holes till pressure is applied externally.

  • CompactFlax@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 days ago

    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.

  • Erik@discuss.online
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

    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.

  • orca@orcas.enjoying.yachts
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

    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.

  • pannenkoek@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    3 days ago

    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 :)

    • deathmetal27@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 days 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.