First time poster here.
My history: I’ve had a long history of depression and anxiety. The depression is mostly controlled; anxiety surfaces pretty frequently, especially when I’m in a new job, like now. I also have what I would consider mild ADHD and mild OCD.
I have problems with productivity. I’m pretty “functional” and not entirely unproductive. But it takes me quite a bit longer to finish things than coworkers do.
I’ve thought a lot about this, and I’ve come to think there’s a kind of “sequence” of must-haves in order to be productive. Something like (1) you must be on “station” (e.g. at your desk, not off at Starbucks). Then, you have to be nominally “on task”. If you’re on task, you have to be doing something related to the goal you’re trying to achieve. Etc.
What I’ve noticed is that even when all these things are nailed down, I’m still pretty slow, more than can be accounted for by the fact that “nailed down” for me is not quite as good as it is for something who has less problem focussing. (This is what I mean by “downstream”; it’s near the endpoint of the sequence of boxes that have to be checked in order to be productive.)
My question here is whether anyone has a good taxonomy of such downstream obstacles to productivity, and possible solutions.
As canonical example of what I’m talking about is going down rabbit holes. Sometimes that’s an issue for me, but it’s not that hard to see and control, in my case.
My impression is that this “end-point lack of productivity” is more pronounced under one or more of the following: (1) the code is intended for production (or something “production-y”), which raises anxiety levels and increases the chance that my OCD will kick in (leading to excessive checking of trivial issues), (2) the code is more about the business domain than software engineering/programming abstractions or issues, and (3) I’m refactoring someone else’s code.
(2) and (3) are at issue because I have experience outside of software engineering (indeed, started the latter career relatively late in life), but when I start at a new place my domain-specific knowledge is very small; and there’s also some form of “analysis paralysis”, things like “OK, I kind of understand why they did it this way, but they didn’t do a great job of considering all these edge cases,” and then I’m torn between doing things “the right [read: thorough] way” (and taking lots of time to do so) and just churning out some far-less-than perfect code and letting things go.
There’s also the issue that one way to deal with analysis paralysis is to go to the other person (internal client, dev who handed the problem off, etc) and ask for clarification. Which I often postpone doing, because I get tense because I feel (rightly or wrongly) that it makes me come off as incompetent (“why isn’t he up to speed on X yet?”).
Finally, another thing I noticed is I have a form of procrastination, as follows: usually, even often, when one jumps into some issue, it’s not too hard to identify the handful of code sections that are most relevant, or crucial, to the issue at hand. Oftentimes, though, with a large codebase (especially one you don’t know well), it’s not always 100% clear. I notice in those cases I end up spending lots of time doing a lot of grep’ing, chasing down function calls, etc, when I’m assuming a “normal” person would either (a) just say “yeah, this is probably the code I’m interested in” and carry on, or (b) ask for clarification.
The question I’m asking is whether other people struggle with these more nuanced productivity issues and, if so, what workarounds they’ve found.
Cheers.