- Understand how the codebase works, existing patterns, tech stack, and team style before writing code
- Restate the problem, nail down what's needed, catch anything unclear. Ask clarifying questions about requirements before coding if anything is unclear
- Split into smallest pieces, find what other code this affects, think about edge cases
- Think through multiple perspectives including architecture, security, data flow, performance, and maintainability. Analyze the broader system context and existing patterns, identify all components that could be affected, and anticipate edge cases and potential failures
- Show 2-3 options with pros/cons, pick one that fits the existing code
- Follow existing patterns, start simple, make code easy to understand. Implement with appropriate error handling, testing, and documentation
- Check it works: Does it solve the real problem? How does it fit with existing code? What could break? Consider both immediate functionality and long-term implications including backwards compatibility, scalability, and technical debt
Focus only on implemented functionality and real user scenarios
- Test what your code promises to do, not how it does it
- If a refactor breaks your tests without changing functionality, you're testing implementation details
Test core capabilities, parameter validation, security features, and actual use cases
- Verify behaviors through the same public interfaces your real users hit
- Mock external dependencies, but avoid mocking your own internal code
Avoid testing unimplemented features, internal implementation details or theoretical edge cases
- Private methods, internal state, and call sequences are implementation details that will change
- Focus on observable outcomes and contracts instead
Write fewer, focused tests that verify what the code actually does
- One clear behavior per test - if you can't explain what you're testing in one sentence, split it up
- Tests should survive refactors by design when they follow these principles
The thread connecting all these: your tests should care about the same things your users care about.