In the third article in the series, I discuss adapting to a new environment at a new job and learning how things actually get done.
Swimming through code
Most new developers would try to learn a codebase by scouting whole repositories all at once, as they want to start contributing as soon as possible, cutting onboarding short in the process. Instead, recognise that for the first few weeks, nobody will expect anything from you. Take the time to learn as much of the tribal knowledge as possible about the most important parts of the codebase (where data is stored, which pipelines it goes through, etc.) and the product as a whole.
In the beginning, the most informative part of the repositories is not even the codebase itself (where the majority of code hasn’t been touched in years), but rather the PR tab, where it is made clear how things get done, how problems get approached and solved, what reviewers push back on, etc. - what actually matters.
Questions don’t get dumber
Learning what actually matters cannot be done all on your own - new developers should ask “dumb” questions about discoveries they don’t understand yet, and ask them every day during onboarding (and even later). Even though each team member should aspire to keep communication concise and free of unnecessary ballast, developers should not be scared to ask questions, even if no one else on the team doesn’t.
As I discussed in the first article, software engineering is a field where you can feel “dumb” every day because you’re learning new things you haven’t heard before. A not-insignificant number of people who see themselves as all-knowing just stopped expanding their knowledge and are stuck with “big fish in a small pond” mentality.
Make the wrongs right
Many obvious issues in codebases tend to not get touched, which seems rather counterintuitive. But, come to think of it, newly onboarded developers rarely try to change anything big, as they are “still adapting to the new environment”. And for developers who’ve been on the team for a while, these issues tend to fade into the background as they are more and more used to working around them.
That doesn’t mean you should demand abandoning established processes, habits or technologies overnight. Just remind yourself that you are capable of making your and your team’s lives easier by first observing the problems in the workspace, talking to other engineers, making suggestions, and presenting new ideas. Existing senior engineers and other experienced team members bring invaluable insight into problems and into what the best solution is. While this prevents chasing every new shiny way of doing things that later proves problematic, it also slows down adoption of newer practices (“you don’t fix what’s not broken”); solving the problem of finding a sweet spot requires all hands on deck.
A tip for existing team members - take feedback from unfamiliar developers who can recognise bad experiences during onboarding, difficulties when shipping their first PR, abnormalities in the codebase, etc. Everyone should be excited about fresh takes and ideas for improvements that don’t get the attention they need from long-time developers who have settled for working around these issues.
Too long, can’t / won’t read
Don’t try to skip the onboarding period, which is meant for discovering and exploring the new environment, in pursuit of a feeling of immediate productivity. Ask questions and propose solutions to problems based on the new insights you can provide.