cakes

Especially if you witness it as an employee and run it up the chain as far as possible and it gets ignored.

Having had good and bad in my career has saved me from realizing that this was happening and that I shouldn't sit idle but if I'm not idle and do something it becomes extremely disheartening to watch this happen (and then I leave when it becomes apparent that nothing will be done and I'm miserable under my manager)

Whatever is easier for you but (if you can) target what they write in

Disagree, I was the not in the "in crowd" with my boss at a previous location and yet I was the person (as suggested) in regards to everything backend related.

This is very true. I'd see this in software I worked on integrating ERPs where we'd have support for like 5-10 custom fields.

The best workflows were those were the custom fields were used and just had a nice label (e.g. "Old Customer Id") and not the workflows where some consultant had created an additional UI that didn't even use the underlying fields and did something like write the data to some unrelated storage mechanism and then building reports that are trying to awkwardly mix and match these data sources.

and also what you work on.

I've been through it working on released and unreleased projects and how things are handled changes based on that

I'd forgotten all about interop with DCOM until just now! Several years ago (when I last had to do it) I recall having to horribly mess with services on my local machine just to get anything to appear to work...let alone actually knowing if it did what I wanted (consistently) and then how to get that to work at a customer site (we were told to document it and throw it over the wall to support...)

I've also started experiencing that even though all actions are cleared and I can navigate away that sometimes those actions "didn't take" and I'd be cleaning up emails for the N-th time.

Generally what parent says and to add: Does the company have a good/stable/solid vision/strategy? Do you believe it is/can execute on it?

It's hard for people to have recall over events and (again not always malicious) what one person may consider a "big deal" to have done (or not done) will influence whether they remember and how they remember it. I've been pulled through changes I was opposed to (in my opinion, it made less sense to make the change) and eventually conceded to the change. 1.5 years later everybody (both those who agreed with me at the time and those who disagreed) was all about changing it again (back to the way it was). I had the email conversations and remembered what previously happened and was able to (re-)inform people about why the decision had been made (no, I did not want to revert all the work I did even if I still thought we shouldn't have made the change).

Yeah there is definitely annoyance, overhead, and expense but you are trying to securely transfer data to an air-gapped network so just "plugging things in" (what some people expect, like just grabbing a usb drive) is a risk in that regard so it's a lot of trade-offs.

the '-C' option to let me do git operations without being in that directory is vastly helpful when I go to script against a variety of git repositories (--git-dir is pretty nice too, I just don't often have a use for it)

This is generally the same experience I have had. I'll even talk through the assumptions (e.g. "Can we assume I know how to do argument checking?") and then after I've done the heavy-lifting of the problem-solving I'm now discussing how I didn't do something I brought up as an assumption.

Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than the few moments I have to digest the question while standing at the board during an interview.

This makes sense and I agree. You will learn some about the domains you write software in but often you are in those by force and not by choice and you will only ever be so interested in the problems you face/software you build. I once got to write a compiler for financial formulas and that was very interesting but that was the exception and not the rule for most of my professional work.

Maybe you get lucky and have a hobby/personal interest that can fulfill this need to some degree (this partially has happened to me, apparently people who write software don't often overlap with people who cross stitch).

I do enjoy writing code but I much prefer writing code for problems or in domains that interest me.