6 Lines That Have Made me Think Recently

I’ve reduced the media I consume. I’ve stuck to books and podcasts while doing the dishes, and occasionally a few forums and indie bloggers via Minifeed.

From those few sources, these lines have made me think recently.

#1. AI won’t take your job. It will change your job description.

#2. The rich have money, the wealthy have time.

#3. Don’t be the best, be the only.

Those three come from Kevin Kelly, the guy behind the 1,000 true fan concept. I’ve been listening to this podcast interview. I don’t know how many dishes I need to wash to finish it.

#4. Hands first, then computer. This is a line I found on Steal Like an Artist. Computers have disconnected us from doing art with our hands.

#5. Momentum isn’t doing more, it’s doing less, but better.

#6. Two hours of focus work today can create a lifetime of income tomorrow.

This comes from Mark Thompson, a veteran marketer I’ve been following recently. I’ve used Mark’s Sales Funnel method to promote my new book.

Friday Links: Leaving jobs, full-stack myth, and stickers

Hey there. Here are 4 main links plus 2 extras I thought were worth sharing this week:

#1. I’d give my junior self lots of advice. But if I had to choose one, I’d say always be ready to leave your job (6min), even if you’re not planning to leave.

#2. I once tried being full-stack, until I discovered the backend world: RESTful APIs and DDD. Maybe being a full-stack coder is a myth (10min) after all.

#3. Here’s a quick take on why polymorphic tables aren’t a good idea (3min).

#4. Could strict best practices and clean code create an unhealthy culture (10min)?

And two quick ones, just for fun:

#a. I had my first laptop full of stickers. If you’re like the old me, share your laptop stickers on stickertop.art.

#b. It seems we coders aren’t the only ones copy-pasting from ChatGPT. Journalists do it too

And in case you missed it, I wrote on my blog about 8 steps to take over a legacy codebase (5min) and when AI feels like cheating (2min).

(Bzzz…Radio voice) This email was brought to you by… Street-Smart Coding: 30 Ways to Get Better at Coding. From Googling to clear communication, it covers 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.

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.