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 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.

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.

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.

Until you have to fix some bug some dude introduced seven years ago and is no longer working at the company.

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.