Learning an Unfamiliar Codebase: Your First Commit
The past few months have been a whirlwind while I’ve been settling into my new position as a software engineer. In addition to gaining new experience in technologies like Backbone.js, Epoxy.js, and C#, I’ve learned a lot about the world of engineering and how to best contribute to my team. One of the most essential things I’ve learned is how to effectively work in an unfamiliar codebase. In this post, I’ll touch on questions you can ask to help you get started.
How is work assigned? Who is my project manager? What form of communication do they prefer? How do I keep my team updated with my progress? How do I know which tasks take priority? How long is a given task expected to take? Who are the stakeholders? What deadlines do I need to keep in mind? Most companies use their own interpretation of Scrum as their software development methodology. Open source projects can rely on github issues to track what work needs to be done.
What is your Git flow? Which branch should I pull from? What naming convention should I use for my branch? Which branch should I make a pull request against? Who should I add to my pull request? Knowing how your new team manages version control will help you cut down on merge conflicts and start to understand the software development lifecycle at your new company.
What environments do I have access to? How do I access the dev environment? How often is it updated? When will my local work be merged in? How is it different from production? Do any other teams use this dev environment? Do I have permission to change it when necessary? What is the etiquette/who do I notify if I change it?
Is there a syntax style guide/linter that I should use? This will increase the readability of your code and help maintain the codebase’s consistency. Also make sure that your IDE uses the same formatting settings as the rest of your team. Example: if your team set their IDE’s to use four spaces instead of tabs, make sure you set yours too.
Who can I reach out to for a high level overview of the codebase? This will allow you to get a jump start on piecing together the architecture and understanding any pain points your solutions will need to account for. If possible, ask the engineer if they’re okay with you reaching out with more detailed questions as you start getting your hands dirty.
What is the goal of this project and what does it do today? Sometimes those can be very different things, especially when working with legacy code. Knowing the goals for this codebase will help you create informed technical decisions, so your solutions steer the project in the right direction.
Are there any internal documentation or learning tools I can refer to? Don’t make the mistake of thinking this is too obvious to ask. People can forget to mention documentation about something that has become second nature for them, but is still new to you. Be prepared though — it’s natural for most documentation to be out of date in some way. Make updates wherever possible to minimize confusion for the next person, your team will appreciate it.
What about any external resources? Your team members all had to go through a ramp up period at one point. How did they navigate? What websites or resources were their lifeline when getting over this learning curve?
Let’s face it — there is no graceful way to learn the ropes. Working in a new codebase for the first time can be an uphill battle, but keeping these questions in mind will save you and your team a lot of headaches. If your team mates aren’t annoyed of you asking questions in your first few weeks, you’re not asking enough!