You say "the Senior", so maybe this also means being in charge of other people? If it's just individual contributor, comment from emeraldd is good advice.<p>If you'll also be a team lead, <a href="https://www.amazon.com/Behind-Closed-Doors-Management-Programmers/dp/0976694026/" rel="nofollow">https://www.amazon.com/Behind-Closed-Doors-Management-Progra...</a> is good book to read on management.<p>Also: spend the first 30 days just listening as much possible, not making suggestions. If there are things that need improving go and try to improve them directly yourself, or do it afterwards. But if there are problems make sure you spend the time to figure out <i>why</i> people are doing bad things, and don't just criticize.
* Learn as much as you can about the system and the currently running stack, deployment model, and dev environment. As a corollary, make sure you can bring a clean stack up on a dev machine, as isolated from prod as possible, by hand. Or as close to by hand as is practical. I've found this to be very important to understanding how things actually work in an application.<p>* Figure out who are you goto people to find out information about the system and the stack.<p>* Figure out who your 'users' are so you know who to ask about actual use cases or end user testing.<p>* Dive in bug fixing, the deeper the dive the better. The more time you can spend in the code base exploring and the faster you get into it the faster you figure out what the real structure is.<p>At least that's my starting point. For me, the big thing to remember is that applications are applications and business processes are business processes. It's all about pipelines that process customers/students/data/whatever and spit them out the other end.<p>Edit: formatting.