[jungler]

I'm moving towards an approach of batch processing more things. What this means in practice is that more of my tasks use limited interactivity - e.g. "draft and redraft" vs "draft and edit". This has the effect of the "yes and" in improv, where I make errors but have to keep going regardless. Working within that mode also means that I can activate on a reflexive, pre-flow state level where I flex the project-management muscles, not the problem-solving muscles. Flow means I am challenging myself, and with so many years of experience, challenging myself means that I am overcomplicating it.

As well, I'm more likely to treat looking up docs as a research project where I copy relevant snippets of the text into one place for easier reference.

I'm still unhappy with a lot of aspects of how I code, but most of it isn't on the end of the day-to-day editing, but rather things like, "oh, I switched languages again - time to relearn the string library".

[ehnto]

That id an interesting take on flow meaning you are overcomplicating things. That explains what was happening to me pretty well I think. I was too bored to reach a state of flow but if it were more challenging I would have been re-inventing something. I have switched domain since I burnt out which is perhaps why I can now find new challenges and be able to reach flow.

[txdejk]

As someone who works in healthcare and has to juggle quite a bit of technical info on quite a few different active individual patients and who has also read other poster's responses above, I'm kinda taken aback that there is such a lack of higher level organization going on. Is it just something that isn't taught or that is but people just don't want or like to do?

[ehnto]

I can only speak for software, but as an industry it doesn't have any clear framework of process at an individuals level. It's all very much left to the individual on how they organise themselves, and a lot of people (including me) never got the memo that it's something you should think about or else there can be consequences (like burn out, inefficiency). Just generally speaking the software industry is a melting pot of loose ideals when it comes to actually working. There are no regulations, no unions, no standard tooling, hell sometimes we make our own tools, set our own hours, move our own goalposts.

I think that's why software companies are often approached with quite a bit of caution by other businesses. It's not like hiring an engineering firm, where you can be pretty certain you'll get an industry standardized result.