Test-Driven Development isn't a religion. It's a tool for design pressure. Apply it where the cost of bugs is high: authentication flows, payment processing, data integrity constraints, permission checks. For UI glue code, integration tests give better ROI. The red-green-refactor cycle forces you to think about the interface before the implementation — that's the real value.

A unit test proves a function returns X given Y. An integration test proves a user can complete a purchase. The gap between them is where production bugs live. Mock at boundaries (DB, HTTP, time), not internal modules. Use real implementations internally. Testcontainers for databases, MSW for APIs. Your CI should spin up real dependencies — the confidence delta is massive.

E2E tests are expensive to maintain. Be ruthless: cover the 3-5 journeys that make or break revenue. Signup-to-value. Checkout. Password reset. Data export. Each test should read like a user story, not a DOM inspection script. Use data-testid attributes, not CSS selectors. Run them on every PR against a staging environment with real data. Flaky E2E tests are worse than none — fix or delete within 24h.

Coverage is a floor, not a ceiling. Configure your CI to fail if coverage drops >2% from baseline. But don't worship the number. 100% coverage on trivial code gives false confidence. Focus coverage energy on: business logic, state machines, error handling paths, security boundaries. Use mutation testing (Stryker) occasionally to find gaps coverage misses.

400 lines of diff is the cognitive limit for a thorough review. Beyond that, reviewers skim. Skimming misses bugs. If a feature genuinely needs 1000+ lines, break it: 1) infra/prep PR, 2) core logic PR, 3) integration PR. Each independently testable. If you can't split it, write a design doc and get alignment before coding. The 'just one big PR' trap costs more in review cycles than the upfront split.

A PR waiting for review is inventory. Inventory rots. Set a team SLA: first review within 24h. Not 'looked at' — meaningful feedback or approval. If you're the only one who can review and you're blocked, the PR is too specialized. Pair program instead. If the whole team is too busy, you're not staffed for the work. Track review latency as a team metric. Fix the bottleneck, not the symptom.

Make testing visible in the PR template. A checkbox isn't enough — require a sentence. 'Added integration test for checkout flow in tests/checkout.test.ts' or 'N/A: only updated Tailwind config'. This forces the author to think about testability. Reviewers check this first. If it's empty, the PR waits. Over time, 'N/A' becomes rare because engineers design for testability by default.

Direct pushes to main bypass every safety net: CI, review, audit trail. Protect the branch. Require PRs. Require status checks. Use merge commits (not squash, not rebase) so the git log reads like a changelog: 'Merge PR #442: Add idempotency keys to payments'. The commit message becomes the release note. Squash merges lose context. Rebase merges rewrite history. Merge commits are honest.

The 'no Friday deploy' rule treats symptoms. The cause is batch size. Small batches: fast feedback, easy revert, low blast radius. Invest in: automated CI/CD, feature flags, canary deployments, observability. If you can't deploy safely on Friday, you can't deploy safely on Tuesday either — you just have more time to fix it. Fix the deployment pipeline, not the calendar.

Flags aren't just for product experiments. They're risk mitigation. Every new code path gets a flag. LaunchDarkly, Unleash, or a simple DB table — doesn't matter. The pattern: 1) Deploy with flag OFF. 2) Enable for internal team. 3) Enable for 5% of users. 4) Watch metrics. 5) Gradual rollout. 6) 100% → remove flag. If errors spike at any step, flip OFF. No redeploy needed. This is how you deploy 50x/day with confidence.

The deploy isn't done when CI passes. It's done when production is stable. Assign a 'deploy buddy' — the author + one other. They watch: error rate, latency p99, business metrics (signups, checkouts), log volume. Have a runbook: 'If error rate > 1%, rollback immediately'. The rollback must be one click. If it takes 10 minutes, you'll hesitate. Automate it.

Before merging: 1) Is the migration reversible? 2) Can the old code read the new schema? 3) Is there a feature flag to disable the new path? 4) Does the runbook say 'run `kubectl rollout undo`'? If any answer is 'no', don't merge. Expand-only migrations: add columns/tables, never remove in the same deploy. Separate cleanup migration. This is how you deploy 100x without a single catastrophic rollback.

Inheritance creates rigid taxonomies. Composition creates flexible building blocks. Instead of `class PaymentProcessor extends BaseProcessor`, use `const processPayment = (gateway, validator, notifier) => ...`. Inject dependencies. Swap implementations for testing. Extend behavior by wrapping, not subclassing. The only inheritance acceptable is interface implementation. Even then, prefer structural typing (duck typing) over nominal.

Business logic: 'given this state and this event, what's the next state and what effects should happen?' Effects: 'actually send the email, actually charge the card, actually write to DB'. Keep them separate. The logic layer returns a list of effects. The edge layer executes them. This makes logic 100% unit-testable with zero mocks. Effects are tested with integration tests. The boundary is explicit — you always know where I/O happens.

The server is the source of truth. The client is a view. When the user acts, send an intent to the server (form submit, API call). The server validates, mutates, returns the new truth. The client re-renders. No optimistic UI without server confirmation. No local state that the server doesn't know about. This eliminates entire classes of bugs: stale caches, race conditions, divergent states. React Server Components, HTMX, Remix — they all encode this.

Stateful APIs (sticky sessions, server-side sessions) couple your infrastructure to your code. They break horizontal scaling. They break rolling deploys. They break multi-region. Use stateless auth: short-lived JWTs, refresh tokens, or opaque tokens validated against a shared store (Redis). The request is self-contained. Any pod, any region, any time. This is how you go from 3 servers to 300 without rewriting.

Blameless doesn't mean accountability-free. It means the question is 'what in our process allowed this human error to become an outage?' not 'why did Bob push bad code?'. The output: timeline, root cause (5 whys), action items with owners and due dates. Action items are: better monitoring, safer defaults, automated checks, clearer runbooks. Never: 'Bob will be more careful'. If Bob could take down prod by being careless, the system failed Bob.

On-call shouldn't burn people out. Rules: 1) Max 1 week primary. 2) Secondary shadows, steps in if primary unavailable. 3) Escalation: primary → secondary → team lead → manager. 4) Compensate: extra day off after on-call week, or on-call pay. 5) Quiet hours: pages only for SEV-1. SEV-2/3 wait for business hours. 6) Runbook for every alert. If an alert has no runbook, delete it. 7) Post-incident review within 48h.

Tech debt compounds like interest. If you don't pay it down, velocity trends to zero. Make it visible: a 'Tech Debt' label in Jira/Linear. Prioritize by: pain (how often it bites), risk (blast radius), leverage (unblocks future work). The 20% is non-negotiable — if leadership pushes back, show the velocity chart. 'We can ship 5 features this sprint, or 4 features + pay debt so next sprint we ship 6.' Numbers win.

Oral tradition scales to ~7 people. Beyond that, you need a library. ADRs: 'We chose X over Y because Z. Date. Author. Status.' Runbooks: 'Alert X means Y. Check Z. Run command A.' Service READMEs: 'Purpose. Dependencies. How to run locally. How to deploy. Owners.' Onboarding: 'Day 1 tasks. Week 1 goals. People to meet.' Write for the person joining in 6 months. That person is usually you.