The Unwritten 80% of Software Engineering

What we cover

One feature. The entire engineering journey.

We take a one-line feature request and follow it all the way to production — and through the incident that follows.

Nobody writes code. Instead, students see everything that has to happen around the code to turn an idea into software a real team can trust.

• Turn ambiguity into something buildable — take “we need a new feature” and turn it into epics, stories, acceptance criteria, assumptions, dependencies, and measurable requirements. “Make it fast” is an opinion. “p95 latency under 300 ms” is something an engineer can design and test for.
• Design while change is still cheap — use a lightweight design document to expose assumptions, failure modes, security concerns, dependencies, and tradeoffs before implementation begins. Because design is the last cheap moment to change your mind.
• Build trust through the repo — see why branches, small pull requests, meaningful commits, reviews, and traceability are not Git ceremony. They are how teams make change understandable, reviewable, and safe.
• Prove behavior before you ship it — connect unit, integration, contract, end-to-end, smoke, and performance testing to the risks each one is meant to catch. Because 95% code coverage can still ship a broken product.
• Build once. Ship with an escape hatch. — follow code through CI, automated tests, versioned artifacts, infrastructure as code, promotion, blue/green and canary releases — with rollback designed in before anyone needs it.
• Make production explain itself — use metrics to find the signal, logs to find the evidence, and traces to find the path. Then walk through a production incident where the first question is not “Who broke it?” but “What changed, who is affected, and how do we restore service?”
• Treat security and cost as engineering decisions — see how ordinary choices such as a public bucket, hard-coded secret, overly broad permission, forgotten cloud resource, or unmonitored infrastructure can become tomorrow’s breach or bill.

This is not a tour of tools. It is a walkthrough of how professional engineering decisions connect from idea → design → code → test → delivery → production → learning.

What You’ll Be Ready to Do

Not just more terminology — a mental model you can use on day one.

• See the whole system — trace a feature from the original requirement through design, repository, testing, CI/CD, infrastructure, production, monitoring, and incident response — and understand where your own work fits.
• Speak the language of an engineering team — use terms such as acceptance criteria, NFRs, p95, pull request, artifact, blast radius, canary, rollback, observability, and postmortem with an understanding of why they matter — not just what they mean.
• Think before you code — ask better questions, surface assumptions, identify dependencies, reason about failure modes, judge blast radius, and recognize which decisions are easy to reverse and which are not.
• Verify what AI gives you — AI can generate code quickly; engineers still have to decide whether that code is correct, secure, testable, observable, maintainable, and safe to ship. You’ll leave with a framework for reviewing, testing, debugging, and taking responsibility for work you did not necessarily write line by line.
• Tell a stronger engineering story in interviews — explain a class project, internship, or personal project in terms of requirements, tradeoffs, testing, failure cases, deployment, and operational thinking — instead of stopping at “I built it in Java/Python/React.”
• Walk into your first team with a plan — spend the first weeks learning the product and architecture, asking questions, understanding the team’s workflow, earning trust through small wins, and only then expanding your impact.
• Carry four habits into every project — name your assumptions, test the edges, make it observable, and make it reversible. Those habits prevent far more production pain than heroics ever will.