35 lines
2.4 KiB
Markdown
35 lines
2.4 KiB
Markdown
# The Clean Coder — Deep Reference
|
|
|
|
Based on Robert C. Martin, *The Clean Coder* (2011). Use this when discussing professionalism, estimation, and sustainable pace.
|
|
|
|
## Professionalism
|
|
|
|
- **Do no harm** — Do not leave the codebase in a worse state. If you must leave a mess, leave a clear TODO and track it. Prefer leaving code better than you found it (boy scout rule).
|
|
- **Know your craft** — Practice (e.g., katas), read, stay current. Estimate only what you understand enough to estimate.
|
|
- **Saying no** — When a request would compromise quality or is unreasonable, say no. Offer alternatives (e.g., "We can do X by date Y if we drop Z" or "We need two more weeks for tests").
|
|
- **Saying yes** — When you commit, mean it. Do not say yes to please and then miss; communicate early if you cannot meet a commitment.
|
|
|
|
## Estimation
|
|
|
|
- **Three-point estimate** — Best / nominal / worst case. Use for planning and risk, not as a single "promise" number.
|
|
- **Velocity** — Use historical velocity for iteration planning. Do not inflate; if the team goes fast once, use that as data for the next time, not as the new permanent commitment.
|
|
- **Uncertainty** — Make uncertainty visible. Prefer ranges and confidence levels over false precision.
|
|
- **Refusal to estimate** — It is professional to refuse to give a date when the request is vague or the work is unknown; offer to break it down first or to give a range after discovery.
|
|
|
|
## Sustainable pace
|
|
|
|
- Sustained overtime reduces quality and long-term output. Occasional crunch may happen; make it rare and recover afterward.
|
|
- Tests, refactoring, and learning are part of the job. Skipping them to "hit the date" creates technical debt and is unprofessional in the long run.
|
|
|
|
## Tests as a requirement
|
|
|
|
- Code without tests is legacy. Writing and maintaining tests is part of professional delivery, not optional.
|
|
- When under pressure, the first thing to protect is the test suite and the ability to refactor safely.
|
|
|
|
## Mentoring and collaboration
|
|
|
|
- **Helping others** — Part of professionalism is mentoring, pairing, and leaving the codebase (and the team) better than you found it.
|
|
- **Collaboration** — Communicate clearly with stakeholders and peers; say no when needed, and offer alternatives when saying yes is not possible.
|
|
|
|
Use this reference when the discussion involves commitment, estimates, saying no, sustainable development practices, or teamwork.
|