{"slug": "episode-1-understanding-requirements", "title": "Episode 1: Understanding Requirements", "summary": "A senior engineer explains to his nephew that understanding requirements is the first step of software development, not writing code. Using a wishlist feature ticket as an example, he demonstrates how a simple description hides many decisions that must be uncovered before coding begins.", "body_md": "*This series follows a fictional conversation between an experienced engineer and his nephew. Every episode explores one stage of how software moves from an idea to production.*\n\n👦 **Nephew:** Uncle, I finished the React course. I finished the RAG course. I can build a chatbot that talks to a PDF. What does a senior engineer even have that I don't?\n\n👨🦳 **Uncle:** Tell me something first. When a civil engineer builds a bridge, what does he do on day one?\n\n👦 **Nephew:** Starts building?\n\n👨🦳 **Uncle:** No. He doesn't touch a single brick on day one. He studies the river — how wide, how deep, how fast the water moves, what happens in the monsoon. The bridge is the *last* thing he does. Understanding is the first thing.\n\n👦 **Nephew:** That's civil engineering. We write code.\n\n👨🦳 **Uncle:** Writing code is not the job. It's the *last step* of the job. Same as English isn't thinking — it's just how you express thinking after you've already done it. Code is a language. You use it to express a decision you already made in your head. The decision-making is the actual engineering. Most juniors skip straight to the language before they've decided anything.\n\n👦 **Nephew:** So what's the first step?\n\n👨🦳 **Uncle:** A ticket. Look at this one.\n\n```\nTitle: Add Wishlist Feature\nPriority: Medium\nStory Points: 5\nSprint: Sprint 24\nReporter: Product Manager\n\nDescription:\nUsers should be able to save products for later.\n\nAcceptance Criteria:\n• Add \"Add to Wishlist\" button\n• Store wishlist in database\n• Show Wishlist page\n```\n\n👦 **Nephew:** Three bullet points. I could build this by lunch — button, POST request, a table, a page. Done.\n\n👨🦳 **Uncle:** Could you?\n\n👦 **Nephew:** ...yeah?\n\n👨🦳 **Uncle:** Read it again. Not as a programmer. As the user standing in a shoe store, deciding whether to buy the shoe today or think about it.\n\n👦 **Nephew:** ...I don't see anything new.\n\n👨🦳 **Uncle:** That's the trap. Four words — \"Add Wishlist Feature\" — look simple because English hides ambiguity very well. Code cannot hide ambiguity. Code demands a decision for every single case. Before you open VS Code, you have to drag every hidden case out into the open.\n\n👨🦳 **Uncle:** Suppose we're building this at Flipkart, not on paper. Watch how many decisions \"save it for later\" is actually hiding.\n\n**One** — who can use this? Any visitor, or only logged-in users? If a guest adds something and closes the app, is it gone?\n\n**Two** — can I add the same product twice? Tap the heart, tap it again — does the database get two rows, or does it toggle off?\n\n**Three** — what if that product gets pulled from the catalog tomorrow? Does the wishlist show \"currently unavailable,\" or does it just disappear?\n\n**Four** — does the list survive logout? Log out today, log in next week — still there?\n\n**Five** — is it private, or can I share my wishlist with someone, like a gift list?\n\n👦 **Nephew:** So I go answer all five myself?\n\n👨🦳 **Uncle:** No — and this is the part that saves your career. You don't get to guess. Even the PM may not have every edge case worked out yet — that's often intentional, the implementation details are left for you to shape. Your job isn't to demand every answer upfront and block the sprint. Your job is to read between the lines, make reasonable assumptions for the minor ones, and only escalate the ones that actually change a schema or an API contract.\n\n👦 **Nephew:** How do I tell which is which?\n\n👨🦳 **Uncle:** Rule of thumb — if getting it wrong means a migration or a broken frontend contract, you ask. If getting it wrong just changes some button copy, you assume and move on.\n\n\"A ticket is not a spec. A ticket is a\n\nsummary. The spec lives in the parts nobody wrote down — and finding those parts is the actual skill.\"\n\n👨🦳 **Uncle:** Look at the bottom three lines again.\n\n```\nAcceptance Criteria:\n• Add \"Add to Wishlist\" button\n• Store wishlist in database\n• Show Wishlist page\n```\n\nJuniors skim this. This is not documentation — this is the *definition of done*. If these three are true, the PM closes the ticket, whether or not you handled guest users, whether or not you handled duplicates.\n\n👦 **Nephew:** So it's basically the exam questions.\n\n👨🦳 **Uncle:** Correct. Everything we just discussed — guests, duplicates, deleted items — none of it is in the exam. Which means either it's assumed obvious, or nobody's thought about it yet. You won't know which until you ask.\n\n👨🦳 **Uncle:** Forget the ticket for a second. Don't think React, don't think Node. Ask one question — why is this feature being built at all?\n\n👦 **Nephew:** ...people save things and forget to come back and buy them?\n\n👨🦳 **Uncle:** Maybe. Or marketing wants a reason to send \"price dropped\" notifications. Or a competitor already has it. The \"why\" isn't trivia — it changes your engineering decisions. If the goal is \"bring users back to buy,\" you'll care a lot about notification infrastructure. If the goal is \"match the competitor's checklist,\" you won't over-build any of that yet.\n\n👦 **Nephew:** Same three bullet points, two completely different systems.\n\n👨🦳 **Uncle:** Now you're thinking like an engineer, not a typist.\n\n👦 **Nephew:** Uncle, this is a lot to hold in my head every time. Is there something I can actually carry into every ticket, not just this one?\n\n👨🦳 **Uncle:** Yes. Three steps. I call it Decode, Default, Discuss.\n\n```\nDecode\n  ↓\nDefault\n  ↓\nDiscuss\n```\n\n**Decode** — read everything. The ticket, the acceptance criteria, the design file, the existing product. Walk it like a stranger — where does a similar feature already live? Favorites, Saved Items, Bookmarks — something usually already exists close to this. And if you're joining an existing project, spend five minutes searching the codebase itself — someone may already have solved 80% of your problem. Out of this, you build a full list of hidden questions, like the five we just found.\n\n**Default** — for every hidden question, you personally decide: is this minor, or does it change a schema or contract? For minor ones, silently pick the sane default and move on — don't even mention it. For major ones, don't leave them blank — propose your own answer anyway.\n\n**Discuss** — now go to the PM, but only with the major ones, batched into one message, each with your proposed default attached: *\"I'm assuming guests can't add products to a wishlist, and it won't persist after logout unless you tell me otherwise.\"* The PM now only has to say yes or no. You haven't handed them a blank design problem, and you haven't disappeared for three days guessing either.\n\n👦 **Nephew:** So I never show up with just questions. I show up with questions that already have my best answer attached.\n\n👨🦳 **Uncle:** That's the whole framework in one sentence.\n\n\"A senior engineer isn't the one who asks the most questions. He's the one who asks the\n\nfewest questions that matter most, because he already filled in the rest correctly by himself.\"\n\n👦 **Nephew:** So all of this — Decode, Default, Discuss — happens before I write one line of code.\n\n👨🦳 **Uncle:** All of it. Thirty minutes here saves you three days of rework later — a wrong schema, a wrong contract, a feature the PM rejects in review because it doesn't match what the business actually wanted. Coding is fast. Undoing a wrong assumption in production is not.\n\n👦 **Nephew:** Okay. Now I open VS Code?\n\n👨🦳 **Uncle:** Not yet. Good — you finally know what to build. Tomorrow you'll learn something even harder: deciding where every piece belongs. That's where architecture begins.\n\nPick any app you use daily. Find one small existing feature — a \"save,\" \"report,\" or \"share\" action.\n\nRun it through the framework yourself:\n\nDon't worry about whether your answers are \"correct.\" The goal is to practice noticing hidden decisions.\n\n**— End of Episode 1 —**", "url": "https://wpnews.pro/news/episode-1-understanding-requirements", "canonical_source": "https://dev.to/surajrkhonde/episode-1-understanding-requirements-415h", "published_at": "2026-07-26 14:34:34+00:00", "updated_at": "2026-07-26 14:59:53.306832+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Flipkart"], "alternates": {"html": "https://wpnews.pro/news/episode-1-understanding-requirements", "markdown": "https://wpnews.pro/news/episode-1-understanding-requirements.md", "text": "https://wpnews.pro/news/episode-1-understanding-requirements.txt", "jsonld": "https://wpnews.pro/news/episode-1-understanding-requirements.jsonld"}}