Documenting Decisions: RFC & ADR

Code only tells you How. Documentation tells you Why. As a lead, your job is to leave a trail of 'Why' so that future engineers don't repeat your mistakes.

1. RFC (Request for Comments)

Before you build, you write an RFC. You outline the problem, the proposed solution, and the rejected alternatives. You invite the whole team to critique it. **Architect Tip:** A good RFC ensures everyone's voice is heard BEFORE the code is written, reducing resistance and bugs.

2. ADR (Architecture Decision Record)

ADRs are short, permanent records of specific decisions. - **Status:** Proposed, Accepted, Superceded. - **Context:** What was the problem? - **Decision:** What did we do? - **Consequences:** What are the trade-offs (e.g., 'This makes us faster but increases DB cost')?

4. Career Mastery

Q: "Nobody reads our documentation. How do I fix that?"

Architect Answer: "Keep it **Close to the Code**. Store your ADRs in a `/docs/adr` folder in your main Git repo. Use Markdown. If documentation is part of the PR process, it becomes part of the team's regular workflow. If it's hidden in a forgotten Wiki, it will rot and die."