Skip to content
ZK’s OpsPathAll roadmaps
LEARNING ROADMAP

Software Engineer

Progress from programming foundations through testing, data design, APIs, system design, and sustainable engineering practices.

beginner 100 hours 28 milestones
WHAT YOU’LL LEARN
01

Engineering foundations

Practice the durable ideas shared by strong codebases.

Programming craft

Data structures, decomposition, correctness, and Git.

01

Model problems with data

60 min · beginner

Choose useful structures and reason about complexity.

Open notes and cheat sheet

Model problems with data: Choose useful structures and reason about complexity. Practice this in a small lab, record one failure mode, and explain the operational trade-off.

GOAL: Model problems with data

1. Define the concept
2. Practice with a small example
3. Verify expected behavior
4. Record a failure mode and recovery step
5. Explain the trade-off
02

Design focused modules

90 min · beginner

Separate responsibilities behind small, stable interfaces.

Open notes and cheat sheet

Design focused modules: Separate responsibilities behind small, stable interfaces. Practice this in a small lab, record one failure mode, and explain the operational trade-off.

GOAL: Design focused modules

1. Define the concept
2. Practice with a small example
3. Verify expected behavior
4. Record a failure mode and recovery step
5. Explain the trade-off
03

Test behavior well

120 min · intermediate

Combine unit, integration, and end-to-end confidence.

Open notes and cheat sheet

Test behavior well: Combine unit, integration, and end-to-end confidence. Practice this in a small lab, record one failure mode, and explain the operational trade-off.

GOAL: Test behavior well

1. Define the concept
2. Practice with a small example
3. Verify expected behavior
4. Record a failure mode and recovery step
5. Explain the trade-off
02

Production systems

Move from working code to dependable services.

Web and data systems

APIs, relational data, security, and operations.

01

Design a clear web API

60 min · beginner

Use resources, validation, errors, and versioning deliberately.

Open notes and cheat sheet

Design a clear web API: Use resources, validation, errors, and versioning deliberately. Practice this in a small lab, record one failure mode, and explain the operational trade-off.

GOAL: Design a clear web API

1. Define the concept
2. Practice with a small example
3. Verify expected behavior
4. Record a failure mode and recovery step
5. Explain the trade-off
02

Model relational data

90 min · beginner

Apply constraints, indexes, migrations, and transactions.

Open notes and cheat sheet

Model relational data: Apply constraints, indexes, migrations, and transactions. Practice this in a small lab, record one failure mode, and explain the operational trade-off.

GOAL: Model relational data

1. Define the concept
2. Practice with a small example
3. Verify expected behavior
4. Record a failure mode and recovery step
5. Explain the trade-off
03

Reason about system tradeoffs

120 min · intermediate

Balance performance, reliability, security, and cost.

Open notes and cheat sheet

Reason about system tradeoffs: Balance performance, reliability, security, and cost. Practice this in a small lab, record one failure mode, and explain the operational trade-off.

GOAL: Reason about system tradeoffs

1. Define the concept
2. Practice with a small example
3. Verify expected behavior
4. Record a failure mode and recovery step
5. Explain the trade-off
03

Software Engineer Foundations: Foundations

Chapter group 1: foundations for Software Engineer Foundations.

Software Engineer Foundations course chapters

Follow each tutorial in order and complete its practical checkpoint.

01

Programming mental models

90 min · beginner

Variables, control flow, functions, and how source becomes a running program.

Open notes and cheat sheet

# Programming mental models ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Variables, control flow, functions, and how source becomes a running program. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools TypeScript, Node.js ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[TypeScript] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Programming mental models
TOOLS: TypeScript, Node.js

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
02

Git and collaboration

90 min · beginner

Commits, branches, pull requests, reviews, and conflict recovery.

Open notes and cheat sheet

# Git and collaboration ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Commits, branches, pull requests, reviews, and conflict recovery. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Git, GitHub ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Git] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

04

Software Engineer Foundations: Core practice

Chapter group 2: core practice for Software Engineer Foundations.

Software Engineer Foundations course chapters

Follow each tutorial in order and complete its practical checkpoint.

01

HTTP and the web

90 min · intermediate

Understand DNS, TCP, TLS, HTTP requests, caching, and browser behavior.

Open notes and cheat sheet

# HTTP and the web ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Understand DNS, TCP, TLS, HTTP requests, caching, and browser behavior. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools HTTP, curl, DevTools ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[HTTP] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: HTTP and the web
TOOLS: HTTP, curl, DevTools

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
02

Build a REST API

90 min · intermediate

Design resources, validation, status codes, pagination, and useful errors.

Open notes and cheat sheet

# Build a REST API ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Design resources, validation, status codes, pagination, and useful errors. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Next.js, Zod, REST ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Next.js] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

05

Software Engineer Foundations: Production systems

Chapter group 3: production systems for Software Engineer Foundations.

Software Engineer Foundations course chapters

Follow each tutorial in order and complete its practical checkpoint.

01

Frontend component design

90 min · intermediate

Build accessible, composable components with loading and error states.

Open notes and cheat sheet

# Frontend component design ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Build accessible, composable components with loading and error states. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools React, TypeScript ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[React] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Frontend component design
TOOLS: React, TypeScript

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
02

State and data fetching

90 min · intermediate

Separate server state, UI state, cache invalidation, and optimistic updates.

Open notes and cheat sheet

# State and data fetching ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Separate server state, UI state, cache invalidation, and optimistic updates. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools React, Next.js ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[React] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

06

Software Engineer Foundations: Operations and architecture

Chapter group 4: operations and architecture for Software Engineer Foundations.

Software Engineer Foundations course chapters

Follow each tutorial in order and complete its practical checkpoint.

01

API and system design

90 min · advanced

Compare monoliths, services, events, consistency, and failure boundaries.

Open notes and cheat sheet

# API and system design ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Compare monoliths, services, events, consistency, and failure boundaries. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Architecture diagrams ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Architecture diagrams] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: API and system design
TOOLS: Architecture diagrams

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
02

Secure software delivery

90 min · advanced

Review dependencies, secrets, input, SSRF, injection, and supply-chain risk.

Open notes and cheat sheet

# Secure software delivery ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Review dependencies, secrets, input, SSRF, injection, and supply-chain risk. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools npm audit, SAST ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[npm audit] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Git and collaboration
TOOLS: Git, GitHub

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
03

Data structures

90 min · beginner

Arrays, maps, sets, queues, stacks, trees, and choosing the right trade-off.

Open notes and cheat sheet

# Data structures ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Arrays, maps, sets, queues, stacks, trees, and choosing the right trade-off. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools TypeScript, Big-O ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[TypeScript] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Data structures
TOOLS: TypeScript, Big-O

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
04

Algorithms and complexity

90 min · beginner

Break problems into steps and reason about time, space, and correctness.

Open notes and cheat sheet

# Algorithms and complexity ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Break problems into steps and reason about time, space, and correctness. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Big-O, testing ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Big-O] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Algorithms and complexity
TOOLS: Big-O, testing

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
05

Clean code and modules

90 min · beginner

Use names, boundaries, interfaces, and composition to keep change affordable.

Open notes and cheat sheet

# Clean code and modules ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Use names, boundaries, interfaces, and composition to keep change affordable. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools TypeScript, ESLint ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[TypeScript] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Clean code and modules
TOOLS: TypeScript, ESLint

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
06

Object and functional design

90 min · beginner

Choose objects, pure functions, dependency injection, and composition deliberately.

Open notes and cheat sheet

# Object and functional design ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Choose objects, pure functions, dependency injection, and composition deliberately. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools TypeScript, design patterns ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[TypeScript] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Object and functional design
TOOLS: TypeScript, design patterns

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
GOAL: Build a REST API
TOOLS: Next.js, Zod, REST

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
03

Authentication and authorization

90 min · intermediate

Hash passwords, manage sessions, protect routes, and enforce roles server-side.

Open notes and cheat sheet

# Authentication and authorization ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Hash passwords, manage sessions, protect routes, and enforce roles server-side. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Auth.js, Argon2, cookies ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Auth.js] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Authentication and authorization
TOOLS: Auth.js, Argon2, cookies

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
04

Relational data modeling

90 min · intermediate

Design entities, keys, constraints, indexes, and relationships.

Open notes and cheat sheet

# Relational data modeling ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Design entities, keys, constraints, indexes, and relationships. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools SQLite, PostgreSQL, Drizzle ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[SQLite] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Relational data modeling
TOOLS: SQLite, PostgreSQL, Drizzle

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
05

SQL and transactions

90 min · intermediate

Write safe queries and use transactions for all-or-nothing business changes.

Open notes and cheat sheet

# SQL and transactions ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Write safe queries and use transactions for all-or-nothing business changes. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools SQL, Drizzle ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[SQL] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: SQL and transactions
TOOLS: SQL, Drizzle

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
06

Testing strategy

90 min · intermediate

Select unit, integration, component, and end-to-end tests by risk.

Open notes and cheat sheet

# Testing strategy ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Select unit, integration, component, and end-to-end tests by risk. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Vitest, Testing Library, Playwright ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Vitest] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Testing strategy
TOOLS: Vitest, Testing Library, Playwright

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
GOAL: State and data fetching
TOOLS: React, Next.js

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
03

Accessibility fundamentals

90 min · intermediate

Make keyboard, screen reader, color, focus, and motion behavior first-class.

Open notes and cheat sheet

# Accessibility fundamentals ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Make keyboard, screen reader, color, focus, and motion behavior first-class. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools WCAG, ARIA ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[WCAG] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Accessibility fundamentals
TOOLS: WCAG, ARIA

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
04

Observability for applications

90 min · advanced

Emit useful logs, metrics, traces, and correlation identifiers without secrets.

Open notes and cheat sheet

# Observability for applications ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Emit useful logs, metrics, traces, and correlation identifiers without secrets. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools OpenTelemetry, logs ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[OpenTelemetry] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Observability for applications
TOOLS: OpenTelemetry, logs

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
05

Performance fundamentals

90 min · advanced

Measure bottlenecks, query cost, bundle size, caching, and latency budgets.

Open notes and cheat sheet

# Performance fundamentals ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Measure bottlenecks, query cost, bundle size, caching, and latency budgets. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Lighthouse, SQL ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Lighthouse] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Performance fundamentals
TOOLS: Lighthouse, SQL

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
06

Queues and background work

90 min · advanced

Move slow work out of requests and design retries, idempotency, and dead letters.

Open notes and cheat sheet

# Queues and background work ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Move slow work out of requests and design retries, idempotency, and dead letters. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Redis, queues ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Redis] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Queues and background work
TOOLS: Redis, queues

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
GOAL: Secure software delivery
TOOLS: npm audit, SAST

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
03

Deploy a production service

90 min · advanced

Configure environments, migrations, health checks, rollback, and runtime secrets.

Open notes and cheat sheet

# Deploy a production service ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Configure environments, migrations, health checks, rollback, and runtime secrets. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Vercel, Docker ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Vercel] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Deploy a production service
TOOLS: Vercel, Docker

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off
04

Capstone: production feature

90 min · advanced

Design, implement, test, observe, and document a complete feature.

Open notes and cheat sheet

# Capstone: production feature ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Design, implement, test, observe, and document a complete feature. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Next.js, Drizzle, Playwright ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Software Engineer Foundations] App --> Control[Next.js] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Capstone: production feature
TOOLS: Next.js, Drizzle, Playwright

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off