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.
It isn't even necessarily just Chesterton's Fences. The problem can just be picking your battles. Processes that are working well enough for the team don't need to be fixed right away to be better, and that'll dump a bunch of cognitive load onto the team in the short term. If you show up and on day one you want to fix 4 different processes, the team is going to hear that over the next 3 months you want to completely change how they do all their work, while they need to keep the rest of their work going. That is moving a whole lot of proverbial cheese all at once. Of course, teams can stagnate, and some of this can be good, but you need to spread it out, do the politics up front to get people to agree that processes need to get upgraded, and ease them into the changes over time.