It’s hard to get yourself acquainted with an established code base. Senior devs have put in the time to orientate themselves quickly.

You’ll be like: “What’s this?! What the heck is that doing?! Where do I find the &%#$ thingymabob?!”. Not understanding a code base can cripple your productivity, kill your confidence and keep you confused.

So here are six steps I’ve found really useful when you’re getting up to speed with how a code base has been put together:

1. Front to Back

You’ve been put on a new project at work and haven’t got clue how it works. First things first: before knowing the code base you need to know the product and how users interact with it.

• Inspect the UI first — what is the user experiencing?
• What’s the first screen that comes up?
• Do you have to sign up and log into the product?
• What kind of device is it primarily made for?
• Where does each link go to?
• What things are being implemented?
• Is there anything strange about how you flow through the product?
• What shows up when you check out the browser inspector?

Know the product before trying to change or add to it. I guarantee you will not be adding value if you don’t understand what problem the product is trying to solve.

2. Tools & Technologies

If you love JavaScript and find yourself working on a C# .NET project, you might feel like you’re learning to code all over again. Not only will the code be different — the tools most likely will be too.

• Do you have all the tools that you need to run this project on your machine?
• If you have older/newer tools will you be able to run the project or will you need to upgrade/downgrade?
• What tools/editor are you using? Are you familiar with them? (If you’re not familiar, what gotcha’s do you need to know about the tools?)
• What shortcuts are you familiar with using?

Don’t try to swim upstream. Get familiar with your project tools, technologies and conventions. The more you try to fight for familiar tools, the less value you’ll be gaining from the tools that are made for that specific job.

3. Design Patterns

Design patterns can be harder to understand if you’re a junior dev but more valuable to figure out from the get-go. Having a microscopic lens on specific areas of a project is an easy trap for making mistakes — because you won’t be able to predict the behaviour of the rest of the project. Understanding the design pattern = understanding the architectural decisions.

• Is the project using MVC (Model, View, Controller)?
• Or MVVC (Model, View, View Model)?
• Or MVP (Model, View, Presenter)?
• React/Redux frontend and a database only? (That’s right, some crazy kids do that! *Cough cough me cough*)
• Maybe none of these!

Figure out how your separation of concerns are being split and you’ll stop seeing a single behemoth of code craziness.

4. Data Flow

Data is the lifeblood of a product. Understanding how it has been set up is one of the most important parts to understanding a project.

• How is the data displayed in the UI?
• How is the data rendered?
• How is state managed? Is state managed in one place or many?
• How does the data move/travel?
• What happens at each stage? Controller? UI? Viewbag/viewdata? Model?
• What form should that data be in? String? Integer?
• How is the data connected in the database?
• How is that data saved and where is it saved?
• Are there any data diagrams available?

When developing you will spend a large amount of time trying to figure out where data is coming/going. Console.log it. Breakpoint it. Check what type it should be. Test all your assumptions of what you think it should be doing and make sure it is.

5. History / Quirks

Old code bases are opinionated and quirky (like your senile Grandpa). Three common ways of discovering quirks about a code base are: through a ReadMe, asking people or finding out when you inadvertently break something. Don’t be that guy.

• Ask people what were the most surprising/horrible things they found out about the code base.
• What looks out of place?
• Are there double ups of folders?
• Are there past versions of the project or segmented parts of the project?
• Were any upgrades done?
• Are there helpful comments in the code?
• Does something just seem weird and possibly points towards bigger problems (code smells)?

People won’t always remember or confess to all the gnarly parts of a code base. But don’t be too quick to judge! Very likely you’ll be explaining about a strange snippet of code you added to a project months earlier. It happens to all of us.

6. Searching

Unless you have a photographic memory finding files in a new code base can drive you crazy. Learn what search tools you have at your disposal and then refine how you use them. For example:

• Full project search
• Per file search
• Search by file name
• Find all references
• Go to definition
• Go to implementation
• Are there any buttons that will show you where your current open file is in the project?

Don’t waste time searching file by file or constantly asking people to show you where things are. You’ve got a lot of helpful search options. Once you know how to use them, you won’t have to rely on others to find things.

Interacting with previously established code is one of the hardest parts about being a developer. It’s also one of the things you’ll do most often. If you want to make advancements as a developer, push through the learning pain. Your future self will thank you for it.