I always start with the test suite. If I'm unfamiliar with the code base I start by trying to break things. When I do this I'm looking for missing assertions,

I always start with the test suite. If I'm unfamiliar with the code base I start by trying to break things. When I do this I'm looking for missing assertions, invariants, or incorrect assertions. I create tests for those. I fix them. If the project I'm working on is smart enough to use property-based testing I look for weak invariants, serializability, or missing assertions. The end goal is to understand the module by exercising it and adding value at the same time. If the code base isn't using property-based testing or has no tests at all I will find a way to add them. It gets the ball rolling for adding some issues to the tracker and provides real value. Keep a journal of your experiences coming up to speed. Once you've grasped a certain corner of the code base review your notes and build some documentation for that code. It will help on-board new developers the next time they come to that code base. As for introducing best practices, as a senior developer, you'll have to build consensus with the rest of the team. In my team the difference between a senior developer and a team lead is the ability to communicate ideas and build consensus around them. Learning how to influence people is the hardest part about building your skill as a senior developer. Senior developers become leaders when they can communicate a proposal and immediately build in feedback from the team and turn that into a real change to the code base, product, and business.