Module 33 Professional Engineering

The Software Development Lifecycle

Writing code is a small fraction of what professional software engineers actually do. Turning a vague business requirement into a clear technical specification. Writing an architecture decision record that captures the reasoning behind a major technical choice. Estimating how long something will take and being honest about uncertainty. Presenting a technical approach to non-technical stakeholders. These are the skills that determine engineering career growth — and they're completely absent from most coding-focused education. Vibe coders can generate implementations quickly but often struggle with the surrounding work: understanding what to build before building it, communicating technical decisions to people who don't code, and navigating the organizational dynamics that determine whether good ideas get implemented. This module addresses that gap by treating software engineering as a professional discipline, not just a technical one. You'll practice turning vague requirements into clear specifications through deliberate questioning. You'll write architecture decision records that capture context, decision, and consequences. You'll learn estimation frameworks that account for uncertainty rather than optimistically assuming the happy path. You'll understand what changes at each stage of an engineering career and what it takes to grow from junior to senior to staff.

What You'll Learn

  • 1
    Requirements Gathering — Turning vague needs into clear specifications
  • 2
    System Design Documents — Architecture decision records, RFC process
  • 3
    Estimation — Why it's hard, how to get better, story points vs time
  • 4
    Working with Product — Translating business goals to technical solutions
  • 5
    Technical Communication — Writing RFCs, giving demos, explaining tradeoffs
  • 6
    Career Growth — From junior to senior to staff, what changes at each level

Capstone Project: Full Feature Lifecycle

Take a realistic, ambiguous feature request — 'add team collaboration to our app' — and work through the complete feature lifecycle: clarifying questions to nail down requirements, a written technical specification with multiple approaches and tradeoffs, an ADR capturing the chosen approach, a time estimate with uncertainty ranges, an implementation plan broken into reviewable chunks, and a demo presentation explaining the technical decisions to a non-technical audience.

Why This Matters for Your Career

The engineers who advance in their careers are not universally the best coders. They're the ones who can communicate clearly about technical decisions, align with business priorities, estimate reliably, and lead projects from requirements to completion. These organizational skills determine who gets assigned to the most important projects, who gets promoted to senior and staff, and who builds a reputation as someone who can be trusted with complex, ambiguous work. Requirements quality is the multiplier on implementation quality. The most elegantly engineered solution to the wrong problem is waste. Engineers who push back on vague requirements, ask the clarifying questions that reveal the actual need, and document constraints explicitly build systems that solve the right problems — which is ultimately more valuable than building them efficiently. Engineering estimation is a skill that improves with explicit practice. Optimistic estimates cause trust failures — project delivery commitments are missed, planning is disrupted, and the engineers who gave the estimates lose credibility. Probabilistic estimation, honest uncertainty communication, and scope negotiation are the practices that build the trust that career advancement depends on.