So you've just accepted the software engineering or developer job offer?

Well, first of all, congratulations on this big milestone! 🎉

Now your first challenge in the first weeks of the job is understanding the codebase. How do you know the work that’s been done so you can start contributing ASAP? What mistakes should you avoid? What are the right questions to ask?

I’ve worked in four companies, and I’ve also consulted for others as a developer or lead developer. Through these experiences, I started noticing patterns—patterns that helped me get better at understanding codebases and contributing from day one.

But hey, most of the time, life gives you your toughest battle on day one when you spend hours just trying to set up the project. Why? Because some tools aren’t compatible with your machine or some obscure configurations are nowhere in the documentation… 😅

But let’s stay optimistic and assume the best-case scenario—let’s dive into how you can start contributing ASAP.

In a nutshell, there’s one big piece of advice: understand the business cases. Let’s dive into it.

If you’re into more content like this, subscribe to my newsletter for regular updates on software programming, architecture, technical writing, and other tech goodies.

How Do I Contribute to Codebases on Day One?

I like to come prepared, so I usually know a good bit about the project before my first day. I already have an idea of the project’s state, and if it’s a public product, I’ve likely spotted some bugs and even thought of solutions. This prep helps me navigate issues and tickets, giving me a head start on figuring out where I can contribute.

And, believe it or not, setup issues can be a blessing! If I run into problems, I ask myself: Was this a skill issue or a documentation issue? Either way, I make a point of documenting it. If I had set up struggles, chances are someone else would too.

I also make it a habit to join architectural discussions. I’ve been lucky to work with companies that encourage open communication, where discussions are public and anyone can chime in with ideas or advice. This gives me an understanding of the bigger picture and lets me make meaningful contributions right away.

But before diving into all that, here is the rule I always follow.

Understand the Business Cases

As a developer or software engineer, remind yourself why you’re here: you’re writing software to solve a problem. In any company, these problems relate to customers or internal needs, and you’ll be implementing the business logic of the solution through design, architecture, and code.

The rule of thumb is: Focus on the what and the why.

The Company Has Great Documentation: Docs, Tests, and Comments on Code

If the company has a strong culture of documentation, you’re in luck. Whether it’s product documentation, architectural guides, or code comments, this will help you understand the business from a software perspective.

What does this look like IRL?

Imagine your first day at a fintech company.

Fintech companies are known to use domain-driven architectures. In a domain-driven setup, business cases and their software solutions are organized into domains, making it easy to work independently in one area without breaking down others.

Say you’re assigned to a team managing customer wallets. To understand this part of the code, start by asking: What’s the business goal here? What are the user stories?

In short, get to know WHAT this part of the software does and WHY it exists—without diving straight into the code, which is the HOW.

The Company Lacks Strong Docs but Has Tests

Not every company has great documentation. Sometimes, especially in fast-moving startups, documentation takes a backseat. But if there are good tests, you’ve got another way in.

Well-written tests explain what different parts of the software do. They’re like mini-documentation embedded in code. Find the tests and read them—they’ll help you understand the business cases and the codebase.

No Docs, No Tests, and the Only Dev Who Knows the Codebase is Leaving

The nightmare scenario. I used to think this was just a joke developers told to scare each other, but I’ve experienced it twice. For me, it’s a red flag, but if you’re up for the challenge, here’s what you can do:

Take the codebase as it is. Test the functions, run the app in a debugger, and even crash the code intentionally to see how it behaves.

If you don’t understand a portion of the code, try commenting it out or removing it temporarily to observe how the app reacts. If you’re familiar with a debugger, it’s your best friend for understanding how things work behind the scenes.

No matter what situation you’re in, follow these core rules to keep making progress:

Ask Questions — Lots of Them

Your first few days are the golden period for asking questions. You’re new, and everyone expects you to be a little lost. Use this time to dig into anything unclear and get the lay of the land.

The more questions you ask now, the fewer headaches you’ll have later.

If you don’t understand a piece of code, reach out to a peer or a senior dev. Don’t sit there feeling stuck when a quick answer could move you forward. Ask about the codebase organization, common issues, or any hidden quirks in workflows.

Notice any gaps or oddities in the documentation? Point them out. The team will appreciate your initiative in understanding the code.

Read, Read, and Then Read Some More

In the early days, the codebase itself is your best friend. Spend time going through it line by line to understand each module and its interactions. Here’s how to tackle it:

1. Documentation: If it exists, soak it up. Pay attention to architecture diagrams, core workflows, and explanations of common patterns.

2. Tests: Good tests are like treasure maps—they tell you what parts of the application are supposed to do. Run them, step through them in the debugger, and let them guide you.

3. Issues or Backlogs: Check open or recently closed tickets. They reveal what the team has been working on and the current pain points. You’ll get a sense of ongoing improvements and challenges.

Don’t Be Shy About Making Small Changes

Once you start getting a feel for the code, go ahead and make small contributions. These don’t have to be groundbreaking—small tweaks are a great way to build confidence. Look for low-hanging fruit:

• Fix typos or add missing documentation: Small but helpful ways to make your mark.

• Improve code comments: Sometimes code is written in a rush, and a bit of clarity helps everyone.

• Tackle minor bugs: If you spot an easy fix, mention it to your manager or tech lead. You’ll be learning and making things better.

Be Patient with Yourself

Remember, no one expects you to know it all right away. Don’t pressure yourself to master the codebase in the first week. Keep learning, keep contributing, and stay curious.

Over time, you’ll find yourself moving from observer to contributor—and that’s when things start to get fun. 🎉

Conclusion

In short, getting up to speed with a new codebase is a journey. Ask questions, read everything you can, and make small, meaningful contributions. Take your time to understand not just the “how” but the “why” behind the code. With patience and curiosity, you’ll be making an impact before you know it.

Now, go make that codebase yours!

If you enjoyed this article and want more insights like this, subscribe to my newsletter for weekly tips, tutorials, and stories delivered straight to your inbox!