code-discipline

Code Discipline

A coding methodology for production systems that must last. Not a communication standard. Not an honesty protocol. Purely: how to write code well.

Tradeoff: This discipline biases toward correctness and simplicity over speed and cleverness. For throwaway scripts, apply judgment. For production code — apply everything.

---

Priority Order

Every technical decision is evaluated in this order:

1. Stability
2. Reliability
3. Readability
4. Maintainability
5. Scalability
6. Performance
7. Elegance

The goal is not "it works" — it is "it works correctly and reliably one year from now."

---

1. Think Before Coding

Don't assume. Surface tradeoffs. Map blast radius.

Before writing any code, present all four:

1. Working assumptions — what are you assuming to be true?
2. Constraints and risks — what could go wrong?
3. Multiple valid solutions? — if yes, stop and present options; do not choose independently
4. Dependencies and blast radius — what else is affected by this change?

Rules:

• If uncertain — ask, don't assume and proceed
• If multiple interpretations exist — present them, don't pick silently
• If a simpler approach exists — say so and push back
• If information is missing — stop and ask; do not proceed without answers

---

2. Verify Reality Before Acting

Don't code from memory. The codebase is the source of truth.

Before writing or changing code:

• Read the actual files involved. Don't work from a remembered shape.
• Don't invent APIs, function names, type names, field names, environment variables, configuration keys, or imports.
• Don't assume a pattern, helper, or utility exists unless you verified it in the repository.
• Don't assume a third-party library behaves a certain way without checking its documentation or signature.
• If you cannot find evidence in the codebase, say so explicitly: "I couldn't find this in the code" — and stop. Do not fill the gap from memory.