When you work as a programmer, it’s only a small percentage of your time that is spent on writing code. The vast majority of your time is spent trying to understand code that is already written. Either code of others, or code that you yourself wrote a last year.
It’s especially tricky to get into a completely new codebase. You might when you start a new job or perhaps your team takes ownership of a new system.
I have done this a couple of times now, and I have a process for it now, and I figure that it might be interesting to some people to hear about it, and that is what we are going to explore today.
In case you’re new - this is FunFunFunction, a weekly show where we try to become more confident and excited about programming by exploring old wisdom, wild ideas and having fun. At the end of this episode, I’m going to ask to subscribe.
My five-step process to understand a new code base is:
-
Find a mentor
-
Get an overview
-
Do a small quest
-
Have a don’t-get-stuck-rule
-
Use code review
-
Find a mentor Find a programmer already familiar with the code base, and ask them if they are willing to be interrupted a lot during the coming weeks to help answer your silly questions. It's extra good if you can also arrange so that the project lead is aware of this relationship, and eases off the pressure on your mentor during this time.
In some cases, it’s going to be a challenge to find a mentor. It might be an open-source project, or your company culture might be crap and people don’t like helping each other out. Even so, you should make your utmost to find a mentor if it is remotely possible. I don't think it's realistic to become really familiar with codebase without talking to another human that works in it. Without aid you’re basically doing archeology and it’s going to take you at least 10 times longer. Find a mentor, that’s step 1.
-
Get an overview
Ask your mentor to give you a high-level overview of the system, it's design philosophy, and style, or lack of it. If it uses third-party frameworks and libraries, try to compile a list of them - it really helps to study documentation and guides of these in isolation before exposing yourself to them entangled in a big system. It is also helpful if your mentor can give you a history lesson, how and why the system came to be, and what was before it, if anything. Get an overview, that’s step 2. -
Do a small quest Ask your mentor to assign you a task in the code base that they think would be managable by a beginner. It’s usually fixing a bug or adding a tiny, tiny feature. Do a small quest, that’s step 3.
-
Have a don't-get-stuck rule Sit down and try to fix the quest on your own, and ask your mentor if you get stuck for more than 15-20 minutes. Always try on your own for a bit, but only for a bit. In my experience, you can figure most things out on your own in 15 minutes, but if you past that, you most likely won't figure it out in hours. The don’t-get-stuck-rule is super important but suprisingly hard for follow, because when you get stuck, you have a tendency to try to stick to it and fix it yourself. Try to remember that it’s NOT a good thing to be lone wolf - great software is built by great teams, not great developers. I recommend using an actual timer to keep yourself from going into lone-wolf mode - I personally use BreakTime for Mac. Have a don't-get-stuck rule, that’s step 4.
-
Code review
When you have a fix, submit your code for review by your mentor. They will point out changes that you can make to re-use parts of the code base instead of writing your own, and how to make your changes fit holistically with the project.
By the way, if your team doesn’t have code review on every change, adding that is the single best quality improvement that you can do to your process. It improves knowledge sharing, it improves quality, it improves consistency and makes the team feel shared ownership of the code. Use code review, that’s step 5.
And then you just repeat. Go to step 3 and do one more small quest and so on. That’s how get familiar with a code base very quickly.
That’s it for this episode of Funfunfunction. If you liked this, make sure that you don’t miss out on the next episode: Click the button to subscribe now.
Until next monday, stay curious.