Six rules I actually work by.
- Research first. I try to learn as much as I can about whatever I’m working on, while watching out for rabbit holes.
- Decisions before implementation. Before I start writing code, I try to settle as many open questions about the problem as I can.
- Understand before you fix. Debugging means diagnosing the cause, not working around the symptom.
- Uncertainty is allowed. An unconfirmed hypothesis has value too, as long as it is labeled as a hypothesis.
- Weigh the costs before building tools. The benefits have to outweigh the cost of building the tool.
- Systems > features. I try to build modules that last throughout production and beyond, though I know that isn’t always realistic.