Netflix deploys to production around 4,000 times every single day. Google ships code thousands of times daily, with zero "release nights." Twenty years ago, the same companies shipped once every six months and prayed nothing broke. The difference is process: sprints, pull requests, code review, CI/CD. This lesson teaches you the playbook your first team will assume you already speak on day one — Jira tickets, daily standups, and what a "merge conflict" actually means.
Learning Objectives
After this lesson, you will be able to:
Describe the full journey of software from idea to live product, and name the key stages involved
Compare three ways teams organize their work (Waterfall, Agile, and Kanban) and explain when each one fits best
Explain the Scrum framework -- its team roles, to-do lists, and regular meetings -- well enough to participate in your first work cycle
Read a project board and understand what Epics, Stories, Tasks, and Bugs mean in a real project
Understand why teams use version control (Git), code sharing platforms (GitHub), code reviews (Pull Requests), and automated testing/deployment (CI/CD) to ship software reliably
Every expert was once a beginner. The people who built Instagram, Zomato, and ChatGPT once had no idea what a "sprint" or a "pull request" was either. You are learning the same playbook they use every single day. By the end of this lesson, you will be fluent in the language of software teams.
Someone in Bengaluru has an idea for an app that helps college students split hostel expenses. Six months later, it is on the Play Store with 50,000 downloads. What happened in between?
The journey from idea to live product follows a surprisingly consistent path, regardless of whether you are building a hostel expense app or a billion-dollar platform like Swiggy. Here are the stages:
Idea -- Someone identifies a problem worth solving
Requirements -- The team figures out exactly what to build (and what NOT to build)
Design -- Architects plan the system; designers create the screens
Code -- Developers write the actual software
Test -- QA engineers verify it works and hunt for bugs
Deploy -- The software goes live for real users
Maintain -- Fix bugs, add features, keep it running
💡
Idea
📋
Requirements
🎨
Design
💻
Code
🧪
Test
🚀
Deploy
🔧
Maintain
The big question is: in what order do you do these steps, and how rigidly do you follow them? That question is the entire reason software development methodologies exist.
What Do You Think?
A startup wants to build a food delivery app. They are not sure exactly what features users want, and user preferences may change fast. Which methodology should they pick?
SDLC stands for Software Development Life Cycle. It is just a fancy term for "the process a team follows to build software." There are several approaches, and each one answers the same question differently: How do we organize the work of building software?
Let us walk through the three most important ones.
Waterfall is the oldest methodology. It works exactly like it sounds -- each phase flows downward into the next, like water cascading over rocks. You complete requirements fully before moving to design. You finish design completely before writing a single line of code. You finish all coding before testing begins.
No going back. Once requirements are signed off, they are locked.
Everything is documented in massive specification documents before anyone touches code.
Good for: Government projects (where requirements are fixed by law), medical device software (where patient safety demands rigid process), banking core systems (where a bug could move millions of rupees incorrectly).
Bad for: Anything where users might change their minds. Startups. Web apps. Mobile apps. Basically most modern software.
The fatal flaw: Imagine spending 10 months building exactly what the client asked for, only to hear at the demo: "Actually, we changed our mind about the core feature three months ago but forgot to tell you." In Waterfall, that means starting over. In the real world, this happens constantly.
Agile was born in 2001 when 17 frustrated software developers met at a ski lodge in Utah and wrote the Agile Manifesto. They were tired of Waterfall projects failing because the world changed faster than the plan.
The core idea: build in small increments, get feedback after each one, and adapt. Instead of spending 10 months building the entire product and then showing it to users, you build a tiny piece in 2 weeks, show it to users, learn from their feedback, and adjust.
The skateboard analogy: Imagine a customer asks you for a car.
Waterfall approach: Spend 2 years building a car. Deliver the car. Hope the customer still wants it.
Agile approach: Week 2: deliver a skateboard (it moves, it works). Week 4: deliver a scooter (faster, has handles). Week 8: deliver a bicycle (even better). Week 16: deliver a motorcycle. Week 24: deliver the car.
At every stage, the customer has something usable. And at every stage, they can say "actually, I realize I do not need a car -- the motorcycle is perfect for my commute." You saved months of work.
Key principles:
Working software over comprehensive documentation
Responding to change over following a plan
Customer collaboration over contract negotiation
Individuals and interactions over processes and tools
Good for: Startups, web apps, mobile apps, SaaS products, AI/ML projects -- basically 90% of modern software development.
Used by: Google, Amazon, Flipkart, Razorpay, Swiggy, every startup you have heard of.
Kanban comes from Japanese manufacturing (Toyota invented it for their assembly lines in the 1940s). Instead of working in fixed 2-week sprints, work flows continuously. Think of it as a conveyor belt rather than a series of boxed time periods.
How it works:
A board with columns: Backlog --> To Do --> In Progress --> Review --> Done
Each card represents a task
Work-in-progress (WIP) limits: You can only have, say, 3 items "In Progress" at once. This prevents the team from starting 20 things and finishing none.
New work gets pulled from the backlog whenever someone finishes their current task
Good for: Support teams (bugs come in continuously, not in planned sprints), DevOps teams (deployments and incidents do not wait for sprint boundaries), maintenance teams.
The key difference from Agile/Scrum: No sprints, no sprint planning, no fixed cadence. Work flows when it flows. The board is the process.
Most teams in the real world use Scrum (a specific implementation of Agile) or a hybrid of Scrum and Kanban called Scrumban. Pure Waterfall is increasingly rare outside of government and heavily regulated industries. Let us dig deeper into Scrum, because that is almost certainly what your first team will use.
Scrum is the most widely used Agile framework in the world. If you join a software team in Bengaluru, Hyderabad, Pune, or anywhere else, there is an extremely high chance they use some form of Scrum. Understanding it before your first day gives you a genuine advantage.
A Scrum team is small -- the 2020 Scrum Guide says typically 10 or fewer people in total. It has three roles:
Product Owner (PO) -- The "what" person. They decide what to build and in what order. They talk to customers, understand business needs, and maintain the Product Backlog (the master list of everything the product needs). Think of them as the captain who decides where the ship goes.
Scrum Master -- The "how" person. They do NOT manage the team. They protect the team. They make sure the Scrum process runs smoothly, remove blockers (if a developer is stuck waiting for server access, the Scrum Master gets it sorted), and coach the team on Agile practices. Think of them as the coach who keeps the team functioning well.
Developers -- The people who actually build the software. This includes frontend developers, backend developers, QA engineers, designers -- anyone who contributes to delivering the product increment. In Scrum, there are no sub-titles. Everyone is just a "developer."
Product Backlog -- The master wish list. Every feature, bug fix, improvement, and technical task lives here. The Product Owner constantly reorders it by priority. Items at the top are detailed and ready to work on. Items at the bottom are vague ideas for the future.
Sprint Backlog -- The subset of the Product Backlog that the team forecasts it can complete in the current sprint. During Sprint Planning, the team pulls items from the top of the Product Backlog into the Sprint Backlog.
Increment -- The actual working software produced at the end of each sprint. It must be "potentially shippable" -- meaning it is tested, integrated, and could theoretically be released to users (even if the team decides not to release it yet).
Scrum has four recurring meetings (called "ceremonies" or "events"):
1. Sprint Planning (Start of sprint, 2-4 hours)
The whole team meets. The Product Owner says "here are the most important items." The developers say "we can realistically finish these 8 items in 2 weeks." They discuss, negotiate, and agree a Sprint Goal plus a forecast of the items they expect to deliver. This is the plan for the next 2 weeks.
Forecast is the right word and it is worth getting right. The team commits to the goal, not to finishing every item on the list. Sprints where one item does not land are normal and are not a failure. A team punished for missing its forecast simply pads the next one, which makes every future plan less useful than the one before it.
2. Daily Standup (Every day, 15 minutes max)
The team stands up (literally, to keep it short) and each person answers three questions:
What did I do yesterday?
What will I do today?
Is anything blocking me?
That is it. No problem-solving, no deep discussions. Those happen offline. The standup is a sync point, not a meeting.
3. Sprint Review (End of sprint, 1-2 hours)
The team demos what they built to stakeholders (the Product Owner, managers, sometimes actual users). "Here is the new checkout flow. Here is the search feature. Here is the bug fix for the payment timeout." Stakeholders give feedback, and that feedback goes into the Product Backlog for future sprints.
4. Sprint Retrospective (End of sprint, 1-1.5 hours)
The team looks inward: What went well? What went badly? What should we change? This is how the team improves its own process. Maybe "our standups are running too long" or "we need better test data" or "pairing on complex tasks worked great, let us do more of that."
Jira is the most popular project management tool in the software industry. Built by Atlassian (an Australian company), it is used by over 100,000 organizations worldwide. If you work in software, you will use Jira (or something very similar like Linear, Asana, or Plane).
Epic -- A large body of work that spans multiple sprints. Example: "User Authentication System." This is too big for one sprint, so it gets broken into smaller pieces.
Story (User Story) -- A feature described from the user's perspective. Format: "As a [user], I want to [action] so that [benefit]." Example: "As a student, I want to reset my password so I can regain access to my account." A story should be completable within one sprint.
Task -- A technical work item that is not directly user-facing. Example: "Set up PostgreSQL database on AWS" or "Configure CI/CD pipeline." Necessary work, but the user does not directly see it.
Bug -- Something that is broken. Example: "Payment fails when amount exceeds 10,000 rupees" or "Profile photo does not load on Android."
The breakdown looks like this: one Epic contains many Stories. Each Story might have sub-Tasks. Bugs float around independently, filed whenever someone discovers a problem.
The Jira board is the visual representation of work. Columns represent stages:
Backlog --> To Do --> In Progress --> Code Review --> QA --> Done
A developer's day revolves around this board. You grab a ticket from "To Do," move it to "In Progress" when you start, move it to "Code Review" when you open a Pull Request, and it moves to "Done" once it passes review and QA.
Imagine 10 people working on the same school project report in a shared Word document. One person edits the introduction while another deletes it. Someone copies the file to their desktop, makes changes, and emails it back with the filename "final_report_v3_FINAL_really_final_v2.docx." Chaos.
Git is a version control system -- software that tracks every change ever made to every file in a project. Think of it like save points in a video game. You can:
Commit -- Save a snapshot of your code at a specific moment. "Save point: added login page."
Branch -- Create a parallel universe where you can experiment without affecting the main code. If the experiment works, merge it back. If it does not, delete the branch. No harm done.
Merge -- Combine changes from one branch into another. "Take the login page from my branch and add it to the main project."
Revert -- Go back to any previous save point if something breaks. "The new payment feature caused a crash. Revert to yesterday's version."
Git is the default nearly everywhere, and it is the one to learn first. You will still meet exceptions: some very large companies run their own systems, and studios working with large binary assets such as game art often use Perforce, because Git handles big binaries badly. The concepts carry over, so learning Git is not wasted anywhere. It was created in 2005 by Linus Torvalds (the same person who created Linux).
Git runs on your local computer. GitHub is a website (owned by Microsoft) where teams store their Git repositories online so everyone can collaborate. Think of Git as your local save files and GitHub as the cloud save that the whole team can access.
4. Pull Request — Ask teammates to review your code on GitHub
✅
5. Merge → CI/CD — Tests run automatically, code deploys to production 🚀
A developer creates a branch (e.g., feat/password-reset)
They write code and make multiple commits on that branch
When the feature is ready, they open a Pull Request (PR) on GitHub -- "Hey team, I built the password reset feature. Here are my changes. Please review."
Other developers review the code -- they read through every change, leave comments, suggest improvements, catch bugs
Once approved, the PR gets merged into the main branch
The branch gets deleted (its job is done)
Pull Requests are where a huge amount of learning happens on real teams. Senior developers leave comments explaining why a certain approach is better, juniors ask questions, and everyone's code quality improves over time.
You do not need to master Git commands right now. Just understand the concept: Git lets multiple developers work on the same codebase without stepping on each other's toes, and Pull Requests are how changes get reviewed and approved.
How Git Branching WorksInteractive
Loading visualization...
Try simulating a basic Git workflow in code. This shows how commits build a history and branches let you work in parallel:
pythonplayground.py · Pyodide
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Tests · Try adding a third branch called feat/settings with two commits. Merge all three branches into main.
You have written your code and it has been reviewed and merged. Now what? How does it actually reach users?
This is where CI/CD comes in -- Continuous Integration and Continuous Deployment. Together, they form the pipeline that takes code from a developer's laptop to the servers that power the app on your phone.
Every time a developer merges code, an automated system kicks in:
The code gets compiled (built)
Hundreds or thousands of automated tests run -- unit tests, integration tests, end-to-end tests
Code quality checks run -- linting, security scans, performance checks
If anything fails, the developer gets an alert: "Your code broke 3 tests. Fix it before merging."
This happens on every single code change, multiple times a day. The word "continuous" means it never stops running. The goal: catch bugs immediately, not 3 months later when the software is in production.
CD stands for two related things and teams use the abbreviation for both. Continuous delivery means every change that passes CI is kept ready to release, with the release itself still a human decision. Continuous deployment goes one step further and releases automatically, with nobody pressing anything.
The difference is that one button. Delivery is far more common, and if you join a bank, an insurer or a medical device company, expect a named person to approve every production release, because the approval itself has to be recorded. No manual uploads. The pipeline handles everything.
The full flow looks like this:
Developer pushes code --> Automated tests run --> If all pass --> Deploy to staging (internal testing) --> Deploy to production (real users)
Even if you are building ML models, not web apps, CI/CD matters. When you train a model and want to deploy it as an API that an app can call, it goes through the same pipeline: automated tests verify the model works correctly, the API gets deployed to servers, and monitoring ensures it keeps working.
Understanding CI/CD is the difference between "I built a model in a Jupyter notebook" and "I shipped a model that 10,000 users rely on every day."
CI/CD Pipeline — From Code to ProductionInteractive
You've now read about sprints, Jira, Git, and CI/CD in theory. Here's what it actually feels like the first time. Most lessons skip this part. The first week is mostly emotional, not technical.
Morning of Day 1. You arrive (or log in remotely). Someone hands you a laptop. The first 4 hours: setting up accounts. GitHub, Slack, Jira, AWS, Datadog, the company VPN, your dev environment. You will hit a permissions error within 30 minutes. This is normal.
Afternoon of Day 1. Your "buddy" or "onboarding manager" walks you through the codebase. You will understand maybe 15% of what they say. You will nod a lot. Take notes — you'll reference them for weeks.
Day 2-3. You try to run the codebase locally. Something breaks. You spend 4 hours on a missing environment variable. The senior engineer fixes it in 30 seconds. This is normal. Senior engineers were once juniors who spent 4 hours on similar problems — that's exactly how they got senior.
Day 4-5. You pick up your first ticket. It's intentionally easy — a typo fix in the UI, or adding a small log line. Your first PR will get 8 comments. Some will sting. None are personal. Code review is brutal but generous: every comment is someone investing 10 minutes to make you better.
Week 2-3. You attend your first daily standup. You don't know what most people are talking about. That's fine — your 30 seconds is "I'm onboarding and pushed my first PR yesterday." Done.
Month 1. You start to feel the rhythm. Standup at 9:30, code in the morning, code review in the afternoon, occasional meeting. The rhythm itself is the productivity tool — not the tasks, but the cadence.
Month 2. You ship a real feature. You see a colleague reference it in Slack. The first time a user benefits from your code, it's a feeling you'll chase for the rest of your career.
Month 3. You stop feeling like an impostor 60% of the time. Now only 40%. (The impostor feeling never fully goes away, even for senior engineers. The trick is just to act anyway.)
#Anatomy of a Code Review (What Your First PR Will Get)
Here's what real comments on a junior's PR look like, with the meta-translation underneath each:
"Consider extracting this into a separate function — it's getting hard to follow."
Translation: "The function is too long. Break it into smaller pieces."
"What happens if user is null here?"
Translation: "You forgot to handle the null case. Add a check or this will crash in production."
"Have you tested this with non-ASCII input?"
Translation: "Indian names with accents, Chinese names, emoji — they'll break this. Test them."
"There's a utility for this in utils/dates.ts."
Translation: "Don't reinvent the wheel. Search the codebase before writing new code."
"This works, but consider the performance implication with 10,000+ rows."
Translation: "Your code is O(n²) — fine for testing, terrible at scale. Make it O(n)."
"LGTM" or "Approved"
Translation: "Ship it. (LGTM = Looks Good To Me.)"
The single most underrated skill on a tech team isn't writing code. It's reading code. Senior engineers spend 4 hours reading for every 1 hour writing. Here is how to read a new codebase efficiently:
1. Start with the README. It tells you how to run things and the basic architecture. If there isn't a useful README, that's information too — about the team's discipline.
2. Look at the directory structure. What folders exist at the top level? src/, tests/, docs/, scripts/. The structure is a map of how the team thinks.
3. Find the entry point. For a web app, this is usually index.html or App.tsx. For a Python service, main.py or app.py. From the entry point, follow imports outward to understand the system.
4. Read tests before reading code. Tests show you how code is meant to be used. Often clearer than the code itself.
5. Git log the file you're editing.git log -p path/to/file.ts shows you every change ever made to that file, with the author. Reading the last 5 commits before you edit something tells you what others have tried and what they learned.
6. Don't try to understand everything. A million-line codebase will never fit in your head. The skill is finding the right 50 lines for the task at hand — not understanding the whole system.
Software development follows a lifecycle: Idea --> Requirements --> Design --> Code --> Test --> Deploy --> Maintain. The methodology you choose determines how rigidly you follow these steps
Waterfall is sequential and rigid (finish each phase before starting the next). Agile is iterative (build small pieces, get feedback, adapt). Kanban is continuous flow (no sprints, just a steady stream of work)
Scrum is the most popular Agile framework: a small team works in 2-week sprints with four ceremonies (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective) to deliver working software every cycle
Jira organizes work into Epics, Stories, Tasks, and Bugs -- a developer's day revolves around picking up tickets, moving them through the board, and getting code reviewed
Git tracks every change to code (commits, branches, merges) and GitHub hosts it online. Pull Requests are how teams review and approve changes
CI/CD automates the journey from code to production -- every change is automatically tested, and if all tests pass, it ships to users without manual intervention
Quick Check1 / 5
Your team has been using Waterfall for 6 months, but clients keep changing requirements every few weeks. Features get built, thrown away, and rebuilt. Morale is dropping. What methodology should the team consider switching to?
Next: Every Document You'll Meet — BRD, HLD, RTM, RCA. You now know the process; the next eight lessons are the parts of the job nobody puts in a job advert. The documents you will be handed with no explanation, what POC and MVP actually mean, the tools, the shape of a real day, what happens when production breaks, timesheets and the bench, and why every hard delivery conversation is the same argument in disguise. This is the half that surprises people in month one.