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.
This helps future me easily find answers to the same questions when I end up having them again, and can eventually serve as documentation when even newer people come into the company.
I've also been taking exquisite notes (online, so searchable), including the same type of long-form links so that even if I have to leave a task for a month, future me can come back to it and pick up the thread immediately.
Taking these notes does slow me down a bit in the short run but I find it is invaluable in the long run.
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.
Do you have a good example of how to go about that?
There are some proprietary services that interface against GPT-3/4[1], though if privacy is a concern, it's getting increasingly easier to self-host LLMs. It seems like every day there's a new open source development that makes these tools more accessible. Just in the last few weeks we've seen llama.cpp, Alpaca, Dalai... New projects are appearing so frequently that it's hard to keep up. Their token size and quality is not yet at the GPT-4 level, so you can't analyze entire codebases yet, but they'd still be useful for smaller chunks of code. And at this pace we can expect great improvements soon.
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.
I wonder if I will ever work at a good job. That would be pleasant.
Not sure your average PhD at Microsoft Research or Jane Street would put up with them. Linux Kernel developers don't use them. Mathematicians don't story point conjectures.
But creating CRUD apps for a non-tech enterprise, you might have lots of "sprints" but no software is delivered reliably or high in quality.
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.