Navigating a Code Basis as a Newbie (and beyond)

A new pupil of mine does a great job. Their current task is to get to know the code basis and implement some smaller features into it in order to do so. What I like about them - They asked me whenever something is unclear. And they asked very good questions so far! However, most of them are questions for which they could find the answers themselves would they only invest 10 more minutes, and here is how ...

The Curse of Impatience ❤️‍🔥

The pupil is full of drive and energy, and thus wants to feel this sense of reward whenever one completes a task. Because of this, they grow impatience pretty fast. And this is nothing new to me, in fact I was just like them when I first started working as a developer.

I remember how my mentor grew progressively tired of me asking questions that I could have easily answered by myself, not because they weren't a good mentor, yet they also had their fair share of work to do. Back then I didn't really see the big deal and now that I am in his shoes, there isn't a big deal. The problem is the context switching my mentor and now I have to go through that sucks a lot of energy from you.

Breaking the Habit ⛏️

So, investing 10 more minutes sounds reasonable and managable for someone eager to deploy their next feature tomorrow. Yet how should these 10 minutes be spend? As I told you before I have been just like them and nowadays are these the things I do in order before going forth and asking a collogue about it:

Zero. Take a Step Back: Get up from your desk, look out of the window for a minute, get a coffee - do something to break that tense feeling in your mind.

1. Planning Before Coding: This is something I always do by now. When I have to implement a more complex feature requiring changes in multiple classes a add comments in each of them outlining what has to be done here and there. Then I start creating a bunch of automated tests before a start the acutal implementation.

This procedure helps me to get an overview of what I have to implement and where the code has to go. A big benefit I see with this is that I can estimate wheter what I had in my mind would theoretically work or not. Therefore, giving me a good head start for the actual implemetation.

2. Git Blame: And no, I don't want someone to screenshot some piece of code, sending it to someone with a message reading: "What did you think when writing this?". In the teams I worked in so far it was a custom to add the ticket number at the beginning of each commit message. With this valuable info one can just open up their ticketing system and search for this specific ticket. If you know what the requirements back then where you will probaly understand why the code is the way it is.

3. Look at the Tests Implemeted: Another way to understand what a piece of code was meant to be doing is to take a look at the implemented tests. Given there are any, they usually give a good overview of what real-life cases the code was intented to be used in. Looking at how the code is used and with which data the calls are supposed to be working should give you a good graps of the domain logic abstracted.

Tip: In some intances, as I looked at the ticket related to this code beforehand, I even add some tests myself when I see them as fitting. This way I can check wheter I understood the requirements correctly and we even get more tests for the code which is always a good thing.

When I do it, I mention it in our daily meeting and create a separte merge request for it. In my team such work is gladly seen, yet check in with your colluges before doing so.

4. Use Break Points: Using the tools provided to us by your IDEs of choice is another option you should consider when stuck in a new code basis. With them you can see which snippets are executed at which point in time and what parameters are thrown all about. In this sense, any kind of debugging you are using in your daily life might also be used in a discovering sense.

5. Break it: Moving a little further away from this conservative approaches - I would claim that we all work with some kind of source control. If I don't seem to unravel the mysteries surrounding the code I need to work with, I simply start removing some of it. That way you can see what test may fail now, which things behave differently and which things simply stopped existing.

I hope these tips may help one or the other developer, pupil or mentor. On my part doing all of them in order until I found what I have been looking for takes about 10 to 20 minutes, yet having years and years of routine with it, this is not suprising. So, don't worry if it takes you a little longer than that!

What are your tips in this regard? I would love to hear them from you and improve my one routine!

Cover image by Yan Krukau! 🥳

Note: When looking into this topic a bit more on our beloved dev.to I also found this well-written post by Nicolas Frankel. Go checkout that post as well if you want even more tips on this topic!