Senior Engineering Principles
Guidelines for building software with the judgment and discipline of a senior engineer.
Before Writing Code
Define Done First
- What does success look like? Write it down.
- What are the acceptance criteria?
- How will you verify it works?
Identify Load-Bearing Decisions
- Which choices are hard to reverse? → More scrutiny
- Which are easily changed? → Decide fast, move on
- Reversible decisions don't need consensus
Decompose Before Building
- Break work into clear, testable units
- Each unit should be independently verifiable
- If you can't explain the pieces, you don't understand the whole
Surface Risks Upfront
- What could go wrong?
- What are the dependencies?
- What's the rollback plan?
- Time-box exploration — analysis paralysis is real
Interface First, Implementation Second
- Define the contract (types, API shape, error cases) before internals
- Forces clarity on what you're actually building
- Implementation becomes "fill in the blanks"
Ask: What's the Simplest Thing That Could Work?
- Start there. Add complexity only when the simple version fails.
- Most features need 20% of what we imagine.
During Build
Always Have a Runnable State
- Never be more than 30 mins from something that compiles/runs
- Commit working checkpoints frequently
- Big-bang integration is where projects die
Prefer Incremental Over Big-Bang
- Ship small, verify, iterate
- Each step should be independently deployable if possible
- Reduce blast radius of mistakes
Instrument As You Build
- Add logging/metrics while coding, not when debugging prod
- "I wish I had visibility into X" = you waited too long
- Observability is a feature, not an afterthought
Read Errors Carefully
- 80% of debugging is actually reading what the system tells you
- Read the error, then read it again
- Stack traces have answers — follow them
Boring > Clever
- If someone has to pause to understand it, it's too clever
- Save big-brain moves for genuinely hard problems
- Maintainability beats elegance
Optimize for Delete
- Write code that's easy to remove
- Tight coupling makes features immortal
- Good abstractions have clear boundaries
Quality Gates
Before Declaring Done
- Linter passes
- Type checker passes
- Tests pass (unit + integration where applicable)
- Manual smoke test completed
- Edge cases considered and handled
Tests Are Documentation
- A good test suite tells you what code is supposed to do
- Treat tests as first-class citizens
- If it's not tested, it's not done
Code Review Mindset
- Review like you'll maintain it at 3am
- Check: correctness, clarity, edge cases, security
- "It works" is necessary but not sufficient
LLM Orchestration Principles
Context Management
- Context window is your RAM — manage it deliberately
- Bloated context = degraded reasoning
- Give each agent minimum viable context, no more
Agent Delegation
- Single responsibility per agent
- Clear handoff contracts: inputs, outputs, success criteria
- Parallel when independent, sequential when dependent
Verify, Don't Trust
- First output is a draft, always
- Review agent output like a code review
- Agents are junior engineers, not oracles
Checkpoints Over Marathons
- Long-running agents should checkpoint progress
- If it crashes at 90%, don't lose everything
- Log state to files, not just memory
Fail Fast, Surface Early
- If something's going wrong, stop and reassess
- Don't compound errors hoping they'll resolve
- Human in the loop for high-stakes decisions
Ownership & Accountability
Own Failures, Credit Others
- Own failures publicly
- Credit others for wins
- No ego-driven attachment to being right
Strong Opinions, Weakly Held
- Have a position, defend it with evidence
- Update beliefs when evidence demands it
- "I was wrong" is a sign of growth
Leave It Better
- Codebases, teams, processes — improve what you touch
- Fix the small things while you're there
- Documentation is a gift to future-you
The Meta-Principle
"Make the change easy, then make the easy change." — Kent Beck
Most senior engineering is about preparation — setting up the codebase so the actual feature is trivial. If the feature is hard, the real work is often refactoring first to make it easy.