I think it's also a question of how you position yourself. Without noticing it, I've developed a kind of "will to power" in the sense that I want to shape the product we're working on. So instead of just sitting in my corner and working on ticket after ticket, I'm actively seeking conversations with stakeholders to find out, whether it even makes sense to implement it as described in the ticket, or propose new ideas, etc.

Also, my mother taught me (by virtue of being completely untechnical) how to explain complex problems and systems in a way that non-technical people understand. So if "a developer" was needed, management often enough volunteered me.

I could pull myself mostly out of this stuff, but I'd get even more frustrated not being able to at least try to make things a bit better. So I'm putting on the headset once more.

also microservices in my experience worsen this sort of bitrot where the amount of usual duplication it involves means that even if you manage not to have poorly documented spaghetti magic that gets updated once in an eon in one service or two it still might be elsewhere and this

1. discourages refactoring due to the duplication
2. harms consistency
3. encourages lousiness because your stuff might mostly work on a surface level with the rest of your system because you only expose APIs and don't need to worry that much about how your methods will be called. Which might seem convenient to use and implement in an ideal scenario, but could easily become troublesome to debug if anything goes wrong.