A practical guide to the habits, standards, and culture that separate teams that ship well from teams that just ship.
Most engineering guides focus on tools. Which framework to use, which linter to configure, which CI platform to pick. Tools matter, but they are not what separates high-performing engineering teams from struggling ones. The DORA research program, which has studied software delivery performance across thousands of teams since 2014, has consistently found that the highest-leverage factors are cultural and behavioral: how code is reviewed, how work is sized and tracked, how teams learn from what they ship, how decisions are documented.
This guide is about those things. It covers coding standards and why consistency reduces cognitive load. It covers conventional commits and why a commit message is a communication artifact, not a formality. It covers code review culture, the definition of done, retrospectives, and the Build-Measure-Learn loop — not as processes to implement but as habits to develop.
It is written for developers and small engineering teams who are past the "get it working" stage and are asking the harder question: how do we keep working well as the codebase, the team, and the product grow?
This is not a methodology adoption guide. It is not an argument for Scrum over Kanban or Shape Up over everything else. It is a collection of practices that have evidence behind them, stated as plainly as possible.
| Audience | How to use this guide |
|---|---|
| Developer on a growing team | Read end-to-end for a coherent mental model of what good engineering habits look like and why they work |
| Tech lead or engineering lead | Use individual sections as reference material when establishing team standards or addressing recurring problems |
| Solo developer or indie developer | Focus on Sections 2, 3, 5, and 11 — the habits that pay off even when working alone |
| Developer joining a new team | Use Section 5 (Definition of Done) and Section 4 (Code Review) to understand what "done" and "good" mean in professional contexts |
| # | Section | Summary |
|---|---|---|
| 01 | What Is Engineering Excellence | Why culture and habits outperform tools and processes; the DORA evidence |
| 02 | Coding Standards and Conventions | Naming, formatting, linting, and the cognitive case for consistency |
| 03 | Conventional Commits | The specification, why commit messages are design artifacts, and how to enforce them |
| 04 | Code Review Culture | The purpose of review, how to give and receive feedback, and why most review cultures fail |
| 05 | Definition of Done | What "done" actually means, why ambiguity is expensive, and how to build a DoD that works |
| 06 | Project Structure and Separation of Concerns | Why structure is a communication tool and how to organize code for maintainability |
| 07 | Development Roadmap and Milestone Planning | Appetite-based planning, milestone design, and how not to over-plan |
| 08 | Agile Without the Ceremony | The Agile values that matter versus the rituals that often do not |
| 09 | Retrospectives That Matter | Why most retrospectives produce no change, and what makes the difference |
| 10 | Build-Measure-Learn | Validated learning, the pivot-or-persevere decision, and how to instrument for insight |
| 11 | Documentation as a Habit | What to document, what not to, ADRs, READMEs that work, and the cost of undocumented decisions |
| 12 | References | Every source cited in this guide, organized by category |
Read Section 1 first. It makes the case for why habits and culture matter more than any specific tool or process — and it does so with data, not opinion. If that argument is not convincing, the rest of the guide will feel like a list of things to implement rather than a coherent philosophy to internalize.
After that, the sections are largely independent. If your team has a specific problem — commits that are unintelligible six months later, code reviews that feel adversarial, retrospectives that produce the same complaints every sprint — go to the relevant section directly.
Sections 7, 8, and 9 are the most opinionated. They make specific recommendations about planning and process that reasonable engineers disagree on. The recommendations are grounded in evidence, but they are recommendations, not commandments. Read the trade-offs and decide what fits your context.
This is the eighth in a series of open engineering reference repositories:
- Product Development Playbook — A 17-phase guide for building tech products from idea to launch
- PERN Stack Architecture Guide — Production-oriented architecture for PostgreSQL, Express, React, and Node.js
- API Design Playbook — REST and API design patterns, versioning, and contract-first development
- Database Design Guide — Schema design, normalization, indexing, and database decision-making
- System Design for Web Developers — Practical system design from a web developer's perspective
- Auth Implementation Guide — JWT, sessions, OAuth2, RBAC, and production-ready auth in Express
- Testing Strategy for Fullstack — Unit to end-to-end testing for PERN stack applications
This guide draws primarily from:
- Accelerate — Forsgren, Humble & Kim (2018) — The DORA research findings on engineering performance
- The Pragmatic Programmer — Hunt & Thomas (2019)
- The Lean Startup — Eric Ries (2011)
- Shape Up — Ryan Singer, Basecamp (2019, free online)
- Extreme Programming Explained — Kent Beck (2004)
- Conventional Commits Specification
- Google Engineering Practices Guide
- DORA Research Program
Full citations are in docs/12-references.md.
Contributions that improve accuracy, add missing concepts, or cite missing evidence are welcome. Read CONTRIBUTING.md before opening a pull request. Claims in this guide must be grounded in evidence — published research, recognized industry standards, or documented practices from credible organizations.
This project is licensed under the MIT License.
Kuril
A dreamer… who still working on it to make it real.
If this guide helped you, consider giving it a ⭐ — it helps others find it too.