8 Proven Steps to Take Over a Legacy Codebase (Without Losing Your Mind)

Like it or not, you can’t escape from legacy code.

I know how it feels to inherit a codebase like that. The “what I’m supposed to do now” feeling. While I’m writing this, my latest gig is yet another legacy code.

I’m not alone. Recently I found this question on Reddit, a fellow coder who received a codebase with only a handoff from a coworker.

I’m about to take over an .NET Core + SQL Server + Knockout.js/Angular project at my company. The issue: There’s zero documentation. I’ll only get a short handover from a teammate…

My main questions are:

• For legacy .NET projects, what’s your process to get up to speed fast?
• Should I start writing my own documentation (README, architecture notes, etc.) while I learn?
• Any tools/tips for mapping out the database + system structure quickly?
• From your experience, what do you focus on first: business logic, database schema, or the code itself?

I’d love to hear how you’ve handled taking over undocumented C# / .NET projects before. Thanks!

Having been in their shoes in every job I’ve had, here’s how I’d approach inheriting a legacy codebase, step by step:

#1. Understand it takes time.

It takes 6-12 months to know the ins and outs of a medium-to-large legacy codebase. Your mileage may vary. The point is: You don’t have to know every single small detail up front.

#2. Install and run the app.

Your first step should be to have your working environment running on your machine.

Install the tools you need: maybe a database engine, editor plugins, or scripts.

Also, this is a good opportunity to document those prerequisites in a README file and to open your first pull request.

#3. List the main components.

Don’t jump to files and methods.

Instead, get to know the overall architecture of the app:

• Is that a monolith? Does it use microservices?
• How many databases does it use?
• Does it call external APIs or services?

You can go as simple or as fancy as you want. Maybe that’s a sketch on a whiteboard or a version-controlled compiled diagram. I tend to go simple with pen and paper.

#4. Learn the building blocks.

Navigate the source code of the main solution or entrypoint.

Try to answer:

• What is the folder structure?
• How is the code organized? Per project? Per domain?
• How does it access the database? Stored procedures? An ORM? Plain SQL queries?
• How does it achieve common tasks like logging, REST calls, etc?

#5. Look for the most frequently changed files.

This is a trick I learned from Your Code Like a Crime Scene by Adam Tornhill.

Those are the places that attract complexity. That’s where bugs tend to happen or where requirements aren’t clear. They’re like the most dangerous places in your code.

If you’re lucky and the code is under version control, use and tweak this Git command,

alias gmost='git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10'

I probably found it on StackOverflow. Or use fancier code analysis tools instead.

#6. Find out the most frequently used features.

Get to know how the end users interact with the app and what the 20% of features they use 80% of the time.

You will find one single screen they use daily, or just a few buttons out of a dozen. “Do one thing and do it well” is often a dream in enterprise software.

#7. Find out the module or component that gets more bug reports.

This is the spot to focus on first or to get early victories.

It doesn’t have to be the same one as the most used component or feature. Maybe it’s a report that runs once a month or a page that takes forever to finish. Or whatever.

Ask users about common pains. Maybe some ex-coworker always mentioned a fix. “Oh, every time that thing broke, Bob mentioned he had to…” You’re like a detective looking for clues.

#8. List key tables and parametrization tables.

Don’t try to understand every detail. Start with the overall design.

Is it one database per client in the same server? Or separate schemas per client?

Then try to generate a diagram from your database schema.

Most likely, you’ll find one or two key tables. Those are the “Reservations,” “Invoices,” or “Orders” tables. They tend to attract more references.

And you’ll also find parametrization tables. Those are tables with only a few records that power the behavior of the system. They’re good candidates for caching.

Parting thought

With those steps, you’ll get a clear big-picture of the codebase. Start broad, then move on to the details when you need it. That’s far better than trying to understand every single class or method up front.

Working with legacy code isn’t glamorous, but it’s the reality of our work. Most of the time, we’re maintaining and modernizing live systems, not building new ones from scratch.

That’s why I dedicate a chapter to legacy code in my book, Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind. Junior me thought I’d only start new projects with the latest tools. Wrong!

Grab your copy of Street-Smart Coding here. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

Wednesday Links: $0.01, layoffs, and Zuckerberg emails

Hey there.

I just realized I already had 4 links and I didn’t want to wait for next Friday to share them. So here they are.

These first two are just for laughs:

#1. Imagine waking up to an invoice for $0.01 from your cloud provider. Yep, that happened. Here’s the full story (10min).

#2. Now imagine sharing a name with the creator of a major social media platform. You won’t believe how many emails you would receive if your name were Mark Zuckerberg (2min).

On a more thoughtful and serious note…

#3. Everybody blames AI for the recent layoffs, especially the ones at Amazon. But there’s a real reason (1min) and of course, nothing to do with AI.

#4. My best interview was just one call and one open source contribution. That happens rarely. But what if open source contributions were like service duty? (2min).

And in case you missed it, I wrote on my blog about the scariest lines of code I’ve written (2min) and my reactions to r/csharp homepage (4min).

(Bzzz…Radio voice) This email was brought to you by… Check my latest book, Street-Smart Coding: 30 Ways to Get Better at Coding. From Googling to clear communication, you’ll find 30 lessons to help you code like a pro. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

See you next time,

Cesar

Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.

Re: I Use AI When I Code. And Sometimes It Makes Me Feel Like I'm Cheating

Is using AI cheating?

That’s a point Christoffer Madsen made in a recent post on dev.to:

I use AI when I code. I don’t hide that. But I also don’t really talk about it. Because sometimes it feels like cheating.

That made me think:

If I copy-paste from StackOverflow, am I cheating?

If I use an open-source library, am I cheating?

If I ask for help, does that count as cheating?

We do those tasks daily. Maybe not always copy-pasting from StackOverflow.

Where’s the line?

When isn’t using AI cheating? It feels like cheating when AI takes full control and writes code we wouldn’t write ourselves.

I do use AI too: to generate boilerplate code and offload boring tasks. That’s where AI shines. But I stay in control, hands firmly on the wheel.

With or without AI, we’re paid to solve problems, not just to write code. If we only turn user stories or specs into lines of code, AI will eat us all alive.

When AI generates code faster than any of us, it’s time to double down on collaboration, communication, and problem-solving. Those skills make us stand out as coders. That’s why I wrote, Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind. Because being a great coder is more than just mastering syntax.

Grab your copy of Street-Smart Coding here. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

4 Practical Use Cases Where AI Shines in Coding

Like many developers, I’ve struggled to find the right way to use AI.

So far, I’ve settled on using AI as my assistant, but I don’t let it touch my code.

I haven’t followed a strict approach to testing AI. I just use it to offload some boring tasks, like this and this.

Here are the use cases where I’ve found AI shines:

#1. Generate unit tests: I give a sample test class I wrote myself and ask it to use as a guideline to generate tests for a similar object. Especially helpful when I’m not doing TDD but still want unit tests.

#2. Generate CRUD code: I’ve always dreamed of automating CRUDs. It seems we’re closer with AI.

I give AI a handler signature, explain the steps, and let it fill in details. I also provide database object definitions, repository signatures, and legacy code blocks, when I’m in migration mode.

#3. Improve naming: OK, this is one of the hardest tasks in coding. I describe what my class or method does and ask AI to critique or suggest names.

#4. Review code: This is one of my most frequent use cases. I like to feed AI with a diff of my changes and ask it to look for typos and places where I broke conventions. AI has caught me copy-pasting a lot. I tend to forget to update API routes. Oops!

I almost added searching (bye Google!) as a fifth point, but I trust StackOverflow and random people’s blogs more. I’m not sure when AI is simply hallucinating or actually answering correctly.

Lesson: Use AI for pattern matching and boilerplate code. Don’t use it to generate entire modules, make architectural decisions, or ask it to “double check answers and not to make mistakes.”

And if you’re starting out, set strict AI rules or you won’t grow strong coding muscles. Use AI as a learning assistant instead.

It’s tempting to default to AI for its speed. But to shine as a coder, you need more than just speed. Coding is problem-solving, collaboration, and clear communication. That’s why I wrote, Street-Smart Coding: 30 Ways to Get Better at Coding, the roadmap I wish I had on my path to becoming a senior coder. Because coding is more than mastering syntax.

Get your copy of Street-Smart Coding here

The One-Liner I Forgot When Writing My Latest Book

Last week, I shared lessons I learned from a team’s architect.

He taught me to simplify complex coding problems into one line. A skill that has become easier with experience.

The same principle applies to any creative work.

But I completely forgot about it when writing and launching Street-Smart Coding, my latest book.

Movies, novels, and TV shows summarize their plot into a line or short paragraph for posters or synopses.

With a one-liner, writing promotional material is easier. “A vampire romance for teenagers.”

Next time you create something, describe it in a single line. You might need it on your sales pages or simply when someone asks you “what’s your new project about?” With a one-liner, you’ll always have a simple, confident answer.