Understanding the code base of your new organization, super fast!

You just joined a new organization as a software engineer and you’re pumped to start climbing up the ladder. You have a checklist to complete which includes downloading the codebase from github, installing slack, setting up a local environment for the API and front end. You finally sort all that out and decide to checkout the code — wow! That’s a lot! Where do you start from?

On your mark, get set…

Start… Start looking at the code. That’s it. We’re done.

👀

Okay, okay… I’ll spill it.

My friends from twitter have some pieces of advice for you on how to do this. Let’s look at those, then I’ll add my 2 cents to it.

Naturally, when anyone joins they try to go over the source that has been given to them. Someone from the team will most likely give you an overview (with depth as well) of what’s happening. For me, having someone that I can comfortably go to for explanation does play an important part. “Comfortably” here involves response time, ability to reiterate, listen, encourage, and also has to be technically good, ‘cos a lot of questions that might be out of scope but may aid my understanding, considering that we’re from different backgrounds, may come up. ~Adamantium

I think the quickest way to do this is to understand the business (speak with biz devs or non tech folks). You probably will understand the codebase anyway so their input should help you understand the problems that the codebase is actually trying to solve ~Blue Chip da I.C.

I think understanding the business and the system works very well. It better helps you understand how each component of the system affects the other so in making changes you know what to look for to be sure you haven’t broken anything. ~Ardil

Product over code

As developers, we sometimes want to skip the docs and meetings around onboarding. We want to just pick up the first task and start writing code. Relax!

Your fastest route to getting around the codebase is to understand the product the code represents. Understanding the product will help you know the end result of every task/ticket and how it fits into the product.

Read the code along a path

Pick a feature and check where it starts from. If it’s a web application, you could inspect the browser to see which endpoint is getting hit, then start from there.

If it’s a github repository, you have the ability to click on functions and then go to where they’re defined. You could open it in VS code and do same — CMD + click should take you to the definition.

The idea is to look at what the code is doing, when you get to a function, class, you go to the definition and see what’s going on there. This should help you understand the code on your own if it’s clear enough. Take it one “functionality” at a time and soon you’ll have an in-depth knowledge of the codebase.

Use tests if you have them

Tests tell you how a class/function is used. You have sample inputs and expected outputs. Check these out to know how to use pieces of code without actually running them.

Use your teammates… Humbly

So far we’ve looked at how to figure out the codebase all by yourself. You really can’t do it all by yourself most of the time so seek help when you have the chance.

Contact them nicely but go straight to the point and don’t waste their time. Senior engineers don’t like “Hi how’re you? How’s coding going? Nice nice!”… No! Try this: “Hey! Do you have some time? How does this work? <fix link of line of code in github here>. Not the exact line but you get the idea right?

By the way, congratulations on getting a new job!

Here’s the tweet that preceded this article: Twitter thread