[samhuk]

From somebody who, perhaps sometimes can be quite full-on about software quality, craftsmanship, and just generally doing good, here's what's helped me in the past when faced with a company/team that has morale, skill, or other problems:

1. "The extent to which you publicly complain about something should be proportional to the robustness of your solution and your confidence in it."

2. If you think things need to be done better, lead by example. I've found that you will be hated for saying things are bad, but loved for proving how things can be good (by example).

3. Note down your concerns (Notion is free!). Wait on them, then talk about them >=1 day later if you still feel like they are valid.

4. Ensure you have enough employable skills on the side so that you can jump ship if the company or your place within it is totally DOA.

[pojzon]

I would like to change many things I feel could be solved in better ways.

Unfortunately Im not a rockstar engineer and stuff takes me more time. I care a lot about maintainability, so writing docs or good explanations to design decisions simply take time.

As you can guess we often dont have that time in the industry thus most things look like they look.

My biggest issue right now is communicating those findings.

Curse of things seeming too obvious, trivial or simply requiring more time.

[intothemild]

I'm an Engineering Manager, i wouldn't consider taking time to do any of the things you listed be what I would consider to be the definition of a "problem engineer".

To me, a problem engineer is someone who blocks the discussion, or that any solution needs to fit the specs of what the problem engineer wants, even before anyone has outlined what the issues are. Basically someone everyone walks on eggshells around. Anyone who breaks collaboration, team work, and especially anyone who ignores good engineering practices just because that makes that specific person happy... Is a problem.. for all the engineers.

You take a little extra time, that's fine. You're taking that time to do good documentation, or writing higher quality code.. you're an engineer, that's what I expect. Higher quality code and better documentation helps boost velocity in so many ways. You're doing yourself, and everyone around you a good service.

Don't beat yourself up.