Google Engineering Practices — CR and MR

I spent about an hour reading Google’s engineering practices (currently focusing on CR and MR). It resonated strongly, so here are my takeaways.

Official docs: link

Standardizing CLs

1. CL means changelist
2. The subject line should be imperative — a concise command that expresses what this change does. Put context and tracking IDs in the body.
3. Don’t batch a pile of unrelated changes into one MR. Large diffs increase review, merge, and rollback risk. Train yourself to split changes and keep each CL as small as practical.

Standardizing MRs

1. For urgent MRs, relax rules appropriately — some changes, if not merged quickly, can cause real business loss.
2. Keep MR comments professional and issue‑focused. The goal is to discuss problems and help developers grow.
3. For stylistic nits without a team rule, accept the existing style.
4. Acknowledge and praise good work.
5. LGTM means “looks good to me”.
6. When resolving conflicts, involve the developer when needed to avoid lost or incorrect code.

Standardizing CRs

1. Speed reduces frustration — don’t let reviews drag on.
2. Issues found in CRs should be fixed by the author, especially serious ones. “We’ll fix it later” is a common path to system decay.

Final Thoughts

1. Google’s write‑up is strong because the issues and explanations map directly to the pain points I’ve hit while pushing CR/MR discipline. It provides a solid theoretical foundation.
2. Great teams don’t face unique problems; they apply more scientific solutions to common ones. The smart approach is to see past symptoms to root causes and fix them properly.