Engineering Cheat Sheet

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

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

Core Engineering Beliefs

Principles Over Tools

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

Progressive Abstraction

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

Code as Craft

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

Document to Scale

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

Speed with Stability

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

Ownership Mentality

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

Non-Negotiables

  • 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.

Naming Conventions

JavaScript / TypeScript

Variables camelCase
Functions camelCase
Components PascalCase
Constants SCREAMING_SNAKE
Files kebab-case

Python

Variables snake_case
Functions snake_case
Classes PascalCase
Constants SCREAMING_SNAKE
Files kebab-case

Go

Variables camelCase
Functions camelCase
Exported Types PascalCase
Packages lowercase
Files kebab-case

Decision Guide

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 to staging to 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.

Development Workflow

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

Additional Resources

Engineering Philosophy Complete Playbook Naming Conventions Development Workflow Git Workflow

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