Engineering Craft
These aren't a layer — they weave through every act.
On this page
The working table of contents.
- Version control as thinking tool — Git isn't just backup. Commits as units of thought, branches as experiments, the DAG as history. Branching strategies (trunk-based vs GitFlow) as team coordination patterns.
- Code review — not about catching bugs (that's what tests do). It's about shared understanding, knowledge transfer, and maintaining standards.
- The testing pyramid — unit tests (fast, many), integration tests (medium, some), end-to-end tests (slow, few). Why the pyramid shape matters. Property-based testing as a level-up.
- CI/CD — every commit gets tested automatically, every merge can go to production. The idea: make deployments boring.
- Observability-driven development — instrument first, then debug. Metrics for alerting, logs for context, traces for understanding request flow. SLOs as the bridge between engineering and business.
- Incident management — on-call, runbooks, postmortems (blameless). The goal isn't preventing all incidents; it's reducing time to recovery and learning from each one.
- Technical decision-making — ADRs (Architecture Decision Records), RFC processes, the art of writing things down so future-you understands why.
- The career ladder — junior (implement solutions) → mid (design solutions) → senior (define problems) → staff (define the right problems) → principal (change what problems mean). The shift from "how good is my code" to "how much leverage does my judgment create".
Going deeper
Branches that earn their own article.
- Git internals (objects, refs, packfiles).
- Code review practices and tools.
- Testing strategies (mutation testing, fuzzing, contract testing, chaos engineering).
- CI/CD pipeline architectures.
- Observability tooling (Prometheus, Grafana, OpenTelemetry, Datadog).
- SRE practices (error budgets, toil reduction).
- Documentation systems (docs-as-code, API docs, runbooks).
- Technical writing for engineers.
- Staff+ engineering resources.