Software engineering career advise is a minefield. Contexts vary so wildly that the best advise probably is more like a case study into personal experiences and how one navigated various delicate/intricate issues.

I for one have two part time jobs and one full time job. My primary challenge has to do with triaging issues ahead of time so that I can draw up a comprehensive plan for working on them ahead of time over the weekend so that I'd be in execution mode throughout the week - which is infinitely more productive - low context switching and more flow.

I also have a mini bottleneck with one company where I'm not given production access - not even readonly and only hear about issues later on from the lead developer. There are often things that I'd rather diagnose in a production env but no - policy dictates part time workers are not given that kinda access.

At the same company, I go to some of the websites we maintain and find somethings are broken and wonder - are these really used by real people or just bots.

We have about 2 mobile apps that do similar things and I'd love to push for a monorepo setup but I have to look around at the engineering culture and realize that a monorepo setup would do more harm than good because it requires a better calibre of engineers.

We have a nestjs codebase full of antipatterns that even I a newbie to nestjs can easily pinpoint and identify - but can't truly get them to consider a huge refactor. I see all manner of nasty rest api implementations that make data flow unintuitive but my leadership skills might be lacking.

I work at a "consulting" firm with a colleague that has issues delegating and primarily prefers import statements be arranged in a particular order. I hated working there because I felt arranging import statements were an insult to my time and abilities as a programmer - but the work pays the bills and I've to bide my time.

I've ranted enough. The bottom line is context varies much too wildly for any advise to be particularly useful beyond being a case study. I'd be more interested in the authors specific experiences than advise