As a software engineer, being an expert on your team's/company's codebase is amongst the most important skills you can have. Here's why:
Knowing your codebase lets you understand the costs and risks associated with any proposed changes. This means you can make more accurate estimates and prevent bugs. Also, you can help identify when's the right time to tackle some tech debt.
Becoming familiar with a codebase takes time, but here are some methods I've used to make this process much faster:
Keep a personal log: of important files, coding patterns, and gotchas. Build it as you learn more.
Speak to experts: First, conduct a preliminary review of the code to identify patterns and questions. Then book a few short calls with experts in your company. If you don't know who they are, ask your manager. Make sure to ask them to point out any important documentation related to the code
Use git smartly: Read through past pull requests and see what files needed to be changed together. Use git blame to see who wrote a particular line of code and reach out for additional context if possible. Use the git pickaxe to find when a particular line was added or removed.
Contribute to documentation: If you find something that you deem important, discuss it with your team. Consider adding code comments explaining the reason for some technical decisions or using a wiki to document these decisions.
Identify and read past RFCs, design docs and ADRs: Do this to understand why some decisions were made and what alternatives were considered.
Repeat as needed when you find a new part of the code you aren't familiar with.
Thank you for reading! ⭐
Also available on my personal blog https://www.victorandcode.com/learn-your-codebase-and-be-10-x-more-effective
Top comments (0)