Episode 2: Exploring the Existing System

👦 Nephew: Uncle, requirements are clear now. Wishlist. Guests can't use it, no duplicates, survives logout. I know what to build. So today I open VS Code and start typing?

👨‍🦳 Uncle: Not yet. Close Jira first.

👦 Nephew: Close it? I need it open, no?

👨‍🦳 Uncle: Not right now. Open the codebase instead. Don't Start. Search.

👨‍🦳 Uncle: Look at the folders on your screen. controllers/ services/ middlewares/ routes/ models/

👦 Nephew: Okay. Where do I start?

👨‍🦳 Uncle: Don't start. Search.

👦 Nephew: Search for what? Wishlist doesn't exist yet.

👨‍🦳 Uncle: Wishlist doesn't. But something like it almost always does. Search for: wishlist favorite saved bookmark

👦 Nephew: …there's a FavoritesService.js in here. And a favorites table already in the schema.

👨‍🦳 Uncle: There it is. Half the time, somebody already solved 80% of your problem - under a different name, for a different feature, a year before you joined.

👦 Nephew: So I just… use FavoritesService for Wishlist?

👨‍🦳 Uncle: Not blindly. You study it first. Open it and ask three things:

• Does it already handle "add," "remove," and "check if exists" the way Wishlist needs to?
• Does it already sit behind the auth middleware, or does it trust the caller?
• Does its database table already store what you need, or just almost what you need?

👦 Nephew: And if it's close but not exact?

👨‍🦳 Uncle: Then you extend it - add a type column so one table serves both Favorites and Wishlist, say - instead of writing a second service that does 90% the same thing under a new name.

What Happens If You Skip This

👦 Nephew: What if I just… don't check? Build Wishlist fresh, clean, my own way?

👨‍🦳 Uncle: Then you write a WishlistService that reimplements the same "is this user logged in" logic FavoritesService already has, sitting three folders away. Now there are two ways to check the same thing in one codebase. Six months later, someone fixes a security bug in one copy - and forgets the other exists.

👦 Nephew: That sounds like a real bug, not a hypothetical one.

👨‍🦳 Uncle: It's one of the most common ones in large codebases. Not because engineers are careless - because nobody searched before building.

The Framework: Search → Understand → Extend

👦 Nephew: Is there something I can carry into every ticket for this, like Decode-Default-Discuss?

👨‍🦳 Uncle: Yes.

Search ↓ Understand ↓ Extend

• Search - before writing anything, grep the codebase for related words. Not just the feature's name - its synonyms. "Wishlist" won't exist, but "favorite," "saved," "bookmark" might.
• Understand - for anything you find, don't copy it blind. Read what it actually does, what it assumes, what it depends on.
• Extend - prefer adding a column, a parameter, a small branch of logic over writing a second version of something that already exists.

👦 Nephew: So the goal is basically…

👨‍🦳 Uncle: Say it.

👦 Nephew: Build the least new code that solves the problem.

👨‍🦳 Uncle: That's it. Senior engineers aren't the ones who build the most - they're the ones who build the least necessary, because every new piece of code is one more thing that can break, one more thing to maintain, one more thing the next engineer has to learn before they can touch it.

Uncle's Line
"The best code you write today is the code you don't have to write - because it already exists, and you were disciplined enough to go look."

👦 Nephew: This isn't really about frameworks or tools then, is it? It's about knowing where to look.

👨‍🦳 Uncle: Exactly. A framework is something you can learn in a weekend. Knowing to search before you build - that's judgment. Nobody can look that up. You either have the habit, or you write the duplicate.

👦 Nephew: Okay. So now I know what to build, and I know what already exists that I can reuse. Now, finally, VS Code?

👨‍🦳 Uncle: Almost. You know the pieces on the shelf. You still don't know how the new piece connects to everything else - what talks to what. Today we walked through the house that's already built. Tomorrow, we draw the map for the new room, and where its doors go.

🧠 Think Like an Engineer - Homework

Pick any app you use daily. Imagine you've been asked to add one small new feature to it - a "pin," "mute," or "hide" action, for example.

• Search - what existing feature in that app do you suspect already does something similar under a different name?
• Understand - what would you want to check about that existing feature before reusing any part of it?
• Extend - what's the smallest possible change you could make to the existing feature, instead of building something new from scratch?

Don't worry about whether your guesses are "correct." The goal is to practice looking before building.

• End of Episode 2 -

Top comments (0)