Ask HN: How to guarantee success at a new job as a Senior Software Engineer?
Just got an offer for a new job as the Senior Software Engineer. What should my first 30 days look like? What did you do to ensure success?
4 comments
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.
If you'll also be a team lead, https://www.amazon.com/Behind-Closed-Doors-Management-Progra... is good book to read on management.
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 why people are doing bad things, and don't just criticize.
If you'll also be a team lead, https://www.amazon.com/Behind-Closed-Doors-Management-Progra... is good book to read on management.
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 why people are doing bad things, and don't just criticize.
Just got the book. Thank you a million! I definitely need to practice listening.
* 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.
* Figure out who are you goto people to find out information about the system and the stack.
* Figure out who your 'users' are so you know who to ask about actual use cases or end user testing.
* 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.
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.
Edit: formatting.
* Figure out who are you goto people to find out information about the system and the stack.
* Figure out who your 'users' are so you know who to ask about actual use cases or end user testing.
* 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.
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.
Edit: formatting.
Some real golden nuggets here. Thank you so much.