Yeah, I thought "flow" required extremely low resistance in the task (i.e., someone sewing, playing an instrument, or playing a relatively simple game competently and with no interruption of confusion, frustration, or distraction).
I wish I could code like that. xD Constant typing to an ambient soundtrack. Instead, it's a minefield of "uh wait I have to Google this thing", "uh, what should happen here?", "oh no, an error with a complicated message I probably also have to Google".
And I can only carry on the rubber ducking to competently deal with those with a FULL MARSHALLING of my mental resources, which seems too strenuous for "flow" and is exhausting after a few hours.
But if you're sewing, you're just sewing.
There were times before I accepted that “massive refactor” is an oxymoron where I would keep some very complicated task lists in my head and manage to recall nearly all of them. Day to day? I can’t remember your name twenty seconds after you’ve told it to me, unless I work at it.
As a code reviewer they should be giving you a compliment sandwich where the criticism or constructive feedback is placed in between two compliments. As a coder, I've found adding async and await to functions does a lot to make your code look sexier to code reviewers even if it doesn't have a perceptible performance impact on non-network calls.
If I were to comment on a new plan for you, I'd say let flow state be your friend and not your enemy. After all, you have a chair you probably have to sit in for ~8 hours a day while you stare at a computer screen full of code and that's hard for anyone to do for that long let alone someone with ADHD. Flow state will give you an advantage over others. Invariably, your flow state will break. Use that time to spend more time talking to the stakeholders in your group because sometimes stakeholders want what they want and nothing else. They'll appreciate the time you took to listen to them, they'll trust and believe in you more (instead of you being an unknown variable), they'll be more confident that they'll get what they want, and you'll benefit from the confirmation bias. If you deliver what they want, it's less likely that their sandcastle will get kicked over -- though still not unlikely.
Getting away from the desk for 5 minutes can give you a lot of perspective, and unstick you from a host of problems. I think if I go back (when I go back?) I'll find a pomodoro app that lets you customize the intervals.
I think I agree with everything except this:
> As a code reviewer they should be giving you a compliment sandwich where the criticism or constructive feedback is placed in between two compliments.
Manageable when the code review is 50 lines. Not so easy to do when it's over 500 lines. Damned awkward when the person outranks you, too. I don't know where the cutoff is, but I feel like there's a point where this advice feels like victim blaming, or at least codependency. Don't put your coworkers in this situation, please.
As for knocking over the sandcastle, I agree this is something all humans wrestle with, maybe developers especially. Almost nobody wants to accept that their code is ephemeral. We always push back. Zen or a little horticulture can give you perspective. Kids might too, but that takes decades to play out. Plants are always changing, and they'll never be exactly the way you picture them in your head for longer than a moment. They're alive, and making them 'do' anything is a negotiation that often goes in directions you didn't anticipate. For good or ill.
But also that Flow state is often a bad way to write code.
One, virtually everyone has a tremendous case of Sunk Cost Fallacy around things done in Flow state. If someone spent 10 hours in a week working on code that you say is badly conceived in a code review, you'll get pushback and grumbling. Argue with someone who did the PR in a single sitting? They will fight you. Hard. This is the most amazing code ever written (because I felt amazing while I was writing it). The rush goes to their heads.
Two, writing code for other people requires empathy. Rumination. Flow state is considerably absent of both of those. So the problems and gotchas you know about ahead of time get handled, but anything you find along the way is very likely to get ignored. The quantity of your code goes way, way up, the quality goes considerably in the other direction.
I made a conscious decision a while back (making official an unconscious one I'd already made) to stop seeking out Flow state. I felt better, but objectively, it hasn't done me any huge favors professionally. From a practical standpoint, me writing less code means that people who write more baroque code than I do at my worst get to set the narrative for larger slices of the codebase. But I've also done something I hate: reason that if a lot of something is bad, none of it is better.
I need a new plan, and I need it bad.