A self-learning course · 50 lessons · extended for technical leadership
Software Design, Mastery Track
Not a collection of patterns or tips — a system for thinking and leading. You learn to see why designs break, balance architectural forces, and take a new initiative from an ambiguous product brief to a measured, safely operated outcome.
Who this is for
You already know how to ship production software. You are the engineer people ask when a design spans modules, teams, or an uncertain roadmap—and you want a repeatable way to make those calls as a tech lead or architect.
This is not a language tutorial, a pattern catalog to memorize, or a generic management course. It connects code-level design judgment to the work senior technical leaders actually carry: clarifying product intent, exposing architectural forces, making consequential decisions, sequencing risk, aligning a small cross-functional team, and owning what happens after release.
The outcome
By the end of this program you will be able to design with judgment — and you will hold the artifacts that prove it.
What you'll be able to do
- Design code that remains clear as it grows.
- Structure systems that evolve without constant rewrites.
- Use AI effectively without sacrificing design quality.
- Make architectural decisions with clarity and control.
- Lead product, design, and engineering from discovery through rollout and learning.
What you walk away holding
Each one produced by a practice task, on your own code:
- A five-point structural checklist you run on any AI output, and the boundary spec you write before generating (lessons 0005, 0010).
- An import table for your folders — which may import which — enforced by a test rather than a README (lesson 0022).
- An inventory of every technology your domain touches, its port, and its fake in tests (lesson 0023).
- A cost ledger with a break-even year in it, for the next build-vs-buy argument (lesson 0027).
- An answered failure inventory — ordering, duplicates, dead letters, tracing — before you adopt a queue (lesson 0031).
- A three-line debt ledger — borrowed, interest, repay-when — for the shortcuts you take on purpose (lesson 0038).
- A complete initiative packet — frame, assumption and story maps, architecture drivers and diagrams, ADR, delivery map, team charter, and rollout contract — traced from outcome to evidence (lessons 0039–0050).
How this course works
Each lesson is a single HTML page you can finish in one sitting. It gives you one tangible win: a concept, shown on real code, then practiced through a short quiz and a task on your own code. Lessons are short on purpose — working memory is small, and storage strength comes from doing, not from reading.
Knowledge
Each lesson points to a high-trust primary source to read or watch.
Skills
Instant-feedback quizzes and practice tasks build durability.
Wisdom
Take the practice tasks to a real community (see resources); trade-offs only become judgment in the wild.
Mark each lesson complete when you finish — your progress appears here. Reference sheets (glossary, principles, patterns, trade-offs) live under reference/ for quick lookup; the glossary is the canonical vocabulary of this course.
Where you are
Completion is kept in this browser's local storage — it does not follow you to another machine, and clearing site data resets it.
Starting somewhere other than the beginning
The lessons are ordered, and later ones assume earlier ones. But if some of this is already yours, start where it stops being true — the honest test is whether you could do the thing today, on your own code, not whether you recognise the words.
| If you can already… | Start at |
|---|---|
| name what is structurally wrong with a function, without running a tool | lesson 0006 |
| say who owns every interface your domain depends on, and why | lesson 0011 |
| make invalid states unrepresentable in code you maintain | lesson 0015 |
| keep every technology behind a port, and run the domain's tests offline | lesson 0027 |
| compare architectural options against measured forces and explain the accepted cost | lesson 0039 |
| none of these comfortably | lesson 0001 |
Skipping forward is cheap. Skipping back is the more common need: every lesson links the ones it builds on, so follow those rather than re-reading in order.
The program, phase by phase
Fifty lessons in four phases — from seeing structure in a single function to owning a cross-functional initiative. The reference documents at the end of each phase are the compressed essence of the course.
Phase I
Core Designer
You learn to recognize structural problems and build code that is clear, resilient, and grounded in the domain.
Reference for this phase: Design Principles and the Glossary.
1. Seeing Structural Problems
Learn to see what's wrong before trying to fix it.
- Identify coupling and cohesion issues in real code
- Apply SRP, DRY, KISS, and YAGNI in context (not as rules)
- Understand the Law of Demeter and why it matters
- Recognize when patterns like Strategy are emerging naturally
- Detect common structural issues in AI-generated code
2. Structuring for Stability
Turn messy code into designs that resist change.
- Design around reasons to change, not just responsibilities
- Replace inheritance with composition where it matters
- Use patterns like Strategy, Adapter, and Facade intentionally
- Control dependency direction with Ports & Adapters
- Guide AI toward better structure instead of patching bad outputs
3. Protecting the Domain Core
Make invalid states impossible.
Phase II
System Designer
You move beyond individual modules and learn to design systems that evolve safely, with stable boundaries and well-directed dependencies.
Reference for this phase: Patterns Quick Reference, indexed by the problem you have.
1. Writing Flexible and Composable Code
Structure code so behavior can evolve without constant rewrites.
- Decide when to use classes and when simple functions are enough
- Inject behavior using strategies and higher-order functions
- Use protocols and abstract base classes to design clean extension points
- Build memory-efficient data pipelines with generators and streaming
2. Managing Complexity in Growing Applications
Prevent complexity from spreading through your codebase.
- Identify and reduce global coupling in applications
- Manage shared state and understand state ownership
- Design practical and maintainable error handling strategies
- Organize modules and folders around responsibilities and boundaries
3. Designing Systems That Scale
Design applications that integrate cleanly with external systems and asynchronous workflows.
Phase III
Master Designer
You learn to make architectural decisions under real constraints, balancing trade-offs while keeping systems maintainable long-term.
Reference for this phase: the Trade-Offs Cheat Sheet — every trade-off below, with the signal that you chose wrong.
1. Managing Complexity Trade-Offs
Learn how to balance flexibility, simplicity, and reuse when designing software.
- Build vs Buy — write both cost ledgers, then apply the differentiator test that overrules them
- Abstraction vs Duplication — price the two rents, and refuse the abstraction that has not been earned
- Configuration vs Convention — run the measured-variation test on every knob, and clear the graveyard
- Generality vs Specificity — tell earned generality from speculative, and strip out the difference
2. Managing System Trade-Offs
Design scalable systems while keeping operational complexity under control.
- Synchronous vs Asynchronous Systems — choose per workflow, and answer the async failure inventory before adopting it
- Consistency vs Availability — cost a stale read against a timeout, per operation rather than per database
- Coupling vs Coordination — choose which currency you pay, and write the compatibility contract down
- Performance vs Maintainability — demand a number first, then hide the hot path behind a deep module
3. Managing Evolution Trade-Offs
Make architectural decisions that allow software to evolve without losing quality.
- Stability vs Speed of Change — slice any large change into small reversible steps, and remove the machinery after
- Isolation vs Integration — draw context lines where meanings diverge, not where the words happen to match
- Correctness vs Delivery Speed — classify a change as reversible or not, and spend the apparatus accordingly
- Short-Term Productivity vs Long-Term Maintainability — take the loan deliberately, and record it with an interest line and a trigger
Phase IV
Initiative Lead
You lead a 6–8 person product, design, and engineering team from an ambiguous brief through discovery, architecture, delivery, rollout, and learning.
Reference for this phase: the Initiative Lead Playbook — every workshop and artifact below, ready to copy.
1. Frame the Work
Turn requested output into a shared problem, credible options, and a thin path to evidence.
- Turn a product brief into an outcome, guardrails, scope, constraints, and explicit unknowns
- Run brainstorming that produces independent options, tested assumptions, useful dissent, and a decision
- Discover behavior, domain language, policies, waiting, and candidate boundaries from a real workflow
- Build a story map and cut executable, end-to-end slices that earn product and technical evidence
2. Design the Smallest Responsible System
Make architecture answer measurable forces, durable state, and consequential decisions.
- Turn vague quality goals into measurable scenarios that shape design and tests
- Use context, container, and dynamic views to choose evidence-based system and ownership boundaries
- Design state transitions, authoritative data, failure semantics, privacy, and compatibility as one contract
- Compare real options, buy targeted evidence with spikes, and preserve reasoning in concise ADRs
3. Deliver, Operate, and Learn
Organize the team and rollout so integration, risk, and outcome evidence arrive while choices remain.
- Sequence a walking skeleton, evidence milestones, dependencies, and an honest forecast
- Establish decision rights, low WIP, collaborative ownership, useful cadence, and objective escalation
- Match tests to risk and release through observable stages with explicit gates and reversal
- Use evidence to continue, change, or stop, then transfer ownership and remove temporary machinery
Reference documents
Lessons are rarely revisited — these are. They are the compressed essence of the course, formatted for quick lookup. Print them; pin them.
Glossary
Seventy terms, A–Z, each with the words to avoid and the lesson that teaches it. If terms conflict with other sources, this document wins.
Design Principles
Nineteen principles, each with its job, the check that applies it, and the way it fails when followed as a rule.
Patterns Quick Reference
Nineteen patterns with a Python skeleton each, indexed by the problem you have rather than the pattern's name.
Trade-Offs Cheat Sheet
All twelve Master Designer trade-offs: the forces, the deciding questions, the default, and the signal you chose wrong.
Initiative Lead Playbook
Twelve reusable templates covering the brief, workshops, architecture, decisions, delivery, team operation, rollout, and closeout.
Resources
Every primary source the lessons cite: books with chapter pointers, articles, talks, and the communities where trade-offs become judgment.
Each reference entry names the lesson that teaches it, and each lesson links back to the entries it uses — so either direction works once you are past the first read.
Before you begin
- Do the lessons in order — later lessons assume earlier ones. Reading one takes ten to fifteen minutes; the practice task on your own code is the part that takes longer and is the part that works.
- Keep your own codebase and one real initiative at hand: the practices produce artifacts you can use at work.
- Bring AI-generated code along: spotting its structural issues is part of the course, not a side quest.
Mission: build the judgment of a senior technical leader — code that stays clear as it grows, systems that evolve without rewrites, AI used without losing control, and cross-functional initiatives led from ambiguity to evidence. Each lesson returns to this.