How do I “get up to speed” in a new codebase? Changing it.

After trying almost every alternative— reading code, docs, tickets, metrics— I’ve found nothing that teaches a system faster than shipping a small change.

Note: I wrote something similar to this a few years ago, which you can read here: Stop Studying, Start Building. That advice was for people learning to code; this is for starting on a new project, which is something you’ll do again and again a programmer. It’s worth trying to do well.

Reading the Code

The first thing I’ve tried is reading the code.

It sounds great: cracking the code open like a book. “Chapter one, __mocks__…”

Or even starting at a logical entry point like index.ts and following a meandering path through the code.

I’ve found this approach to be inefficient. In a new project, it can be challenging to know what code is important. Try as you might, you’ll end up in a few strange, dusty corners.

Reading the Docs

Another thing I’ve tried is reading the project docs: READMEs, generated API docs, static HTML docs, and knowledge repositories.

If you have them— which is not a given— they’ll cover a fraction of what the application does. They can’t convey the full operational reality of the project.

Linus Torvalds once said: “Talk is cheap. Show me the code.” To put it another way, the code doesn’t lie, and being in the code is going to be more authoritative than reading docs.

Static Analysis

Here’s a random thing that I’ve tried that’s very me: evaluating the codebase with static analysis tools.

Tools like linters, auto-formatters, type-checkers, code quality or test coverage libraries, reading and running tests, or generating visuals like an object-relational diagram.

I admire the effort to leverage tooling. But data is not the beating heart of your project. It’s like saying, “It’s a 4/4 song in C major,” when you could hit play on the record.

So, how do we do that, you ask? Start making changes.

How I Get Up To Speed: Start Making Changes

Here’s my best alternative: pick a small ticket and dive in. In a short time, you’ll learn:

  • How to set up the app
  • Who holds institutional knowledge
  • How tickets are assigned and who “owns” things
  • Team standards for code quality, testing, reviewing, and merging
  • Deployment and verification

It’s an organizational speed-run, and that stuff matters. These are not soft skills, they’re hard facts about how your team works.

As a bonus, you get to add value to the project immediately. New person is shipping!

Start Making Changes

As challenging as it can feel, this is it.

Get out there, teaching, asking questions, succeeding, and occasionally failing in public. When you first join a team, nobody expects you to be the expert. That’s the moment to dive in and become a part of the system.