Semi-related piece of advice for younger folks:

When you join a new team, don't try to change team tools, processes etc. starting in the very first week.

Most things are the way they are for a reason. Your "obviously better" idea may lack the full context. Start with observing the situation, talking to people to build understanding and historical context, and don't jump to conclusions too early.

Sometimes you'll be right, and things are suboptimal and based on long-outdated assumptions. Then, it's great to change them and improve! Freshman eyes are great for spotting such inefficiencies, and "new blood" is critical to make the team well-functioning and to improve the legacy stuff.

But improving and rewriting everything all the time has a cost. If you do too much of it too quickly, the team loses the understanding of long-stable processes and things. You may become a bottleneck as the "last person who touched this" in too many areas. People also have limited bandwidth to support your "rewrite everything" ideas every day, while trying to move on with their tasks.

Don't hesitate to suggest improvements, but please be mindful about the volume - especially in times of AI where everything can be vibecoded in an hour.

Finally, some "objectively better" things have no business justification. Improving performance of a piece of code than runs once a month? There's probably 10 more important things to do in your backlog.

Chesterton's Fence. I recommend people read more into this and other concepts in mental models, such as logical fallacies.