Engineering Cheat Sheet

Essential principles, conventions, and decision guides for daily development work.

Version 1.1 · Last Updated December 2025 · Print for Quick Reference

Core Engineering Beliefs

Deep understanding matters more than superficial mastery of frameworks. Concepts drive tool choices.

Build simple first, then abstract. Avoid premature optimization that obscures clarity.

Write for humans first. Clean, understandable code shows respect for future readers.

Documentation is an act of generosity to teammates and your future self.

Move fast without shipping broken things. Testing and reviews safeguard quality.

If you ship it, you own it. Monitor, maintain, and improve what you build.

Every pull request gets reviewed. No self-merges. Feedback must be kind, clear, and constructive.
Tests are mandatory. 80% coverage target for core services. No broken code in main branches.
Never commit secrets. Use environment variables and secrets managers. Check before pushing.

Should I ship without tests? No. Write at least unit tests for business logic. Integration tests for user-facing features.

Should I self-merge my PR? No. Get one approval minimum, unless you’re a tech lead handling an emergency hotfix.

Should I abstract this code? Only if you’ve used it three or more times. Build simple first, abstract later.

Should I skip documentation? No. At minimum: what it does, how to run it, and any known issues.

Should I deploy to production? Only after dev → staging → tech lead approval. Monitor for at least one hour after.

Should I refactor this duplicated code? Yes, now. Don’t postpone improvements. Make the codebase better every time you touch it.

Start with Why — Understand the user need before writing code. Link to issues or document the requirement.
Design Before Code — Think through architecture first. Draw diagrams or write brief design docs for complex features.
Build Simple — Start with the simplest implementation. Avoid premature optimization or abstraction.
Test Thoroughly — Write tests that cover happy paths and edge cases. Run locally before pushing.
Refactor as You Go — Clean up duplicated code and unclear logic immediately while context is fresh.
Submit for Review — Use PR template. Include clear description, screenshots for UI, and test instructions.
Address Feedback — Respond within 24 hours. Make changes or discuss alternatives. Reviews are collaborative.
Monitor After Deploy — Watch logs and metrics for at least one hour. Address issues quickly or revert if needed.

These aren’t rules to slow you down—they’re guardrails to help you move faster, together.