I am about to start a new job working on a huge established code base. The existing team is about 15-20 people and am going to be joining as a staff engineer. I have been thinking about what would my initial days/weeks look like outside of the companies onboarding meetings.
Do you setup 1-1s with everyone on the team? How do you go about figuring out the right areas to contribute? How should I work on building relationships in the initial days?
Here are some of the things you can to do:
1. Show improvement each time, whether that's your understanding of the systems, team culture, expectations or needs. This shows your team that you are learning.
2. Produce notes, documents or graphs, this tend to validate your standing amongst the team especially the team lack comprehension documentation. For example, I produce a lot of Miro/whiteboards on system interaction as well as business flow. Every team I've worked with love those graphs and notes. I still get questions from teams that I've moved on for years.
In order to avoid being annoying, these days I write out my questions in long-form with context, steps taken, etc. which may or may not be worthwhile but it makes me feel better about it. Sometimes, however, I will post this super long question in our Slack channel and the whole problem was a tiny little thing I forgot to do. Asking questions is just awkward, so I put extra effort into embracing that. Hopefully it doesn't backfire. So far, so good.
Definitely do one-on-ones with all your teammates even if it seems pointless. Most of your interactions with them will not be noteworthy, but it's all about the few exchanges that are.
Also, read any technical documentation about the product, team/company processes, etc. You can quickly get an idea of how well the product is maintained if the documentation is up to date. If not, then submitting documentation patches is a good first step your teammates will appreciate.
But generally, you want to start small, on tasks that will expose you to the ins and outs of the codebase, and you want another more experienced dev to be ‘on call’ to help you out when you get stuck for the first few sprints. That’s the kind of support you wanna look for.
good luck.
Another idea could be to just look at recent merge requests to find what recent code changes were
While I could work almost fully remote and come into the office 1 time a week, I opted to work in the office 5 days a week because I know personal connections with people matter, especially when trying to ask questions or figure things out.
Review the notes you take! I use Obsidian, but there are plenty of other applications.