Ensuring Code Quality Under Time Pressure

Under pressure I still separate what I will not ship without from what can follow in a tracked ticket — my rule is three non-negotiables before any merge: focused tests on the primary path and the scariest failure mode, no new security surfaces, and a feature flag or fast rollback path so I can kill the change without a full redeployment. Everything else is deferrable if I ticket it honestly and communicate the follow-up timeline to stakeholders.

When a launch compressed our rate limiter timeline from six days to three, I proposed cutting configurability for the first version — fixed-window enforcement in Redis, tests covering both the enforcement path and Redis-down graceful degradation, a flag to disable the limiter remotely, and a backlog item for the configurable rules engine. I kept green CI and insisted on at least one thoughtful code review even though the calendar was ugly, because skipping review under pressure is exactly when subtle pool-exhaustion or locking bugs slip through.

Launch stayed stable, the follow-on configurability shipped the next sprint, and nobody had to page at two in the morning. The tip I always close with: interviewers care that you can name the tradeoffs explicitly and negotiate scope instead of pretending deadlines do not exist. Saying you never cut corners is not credible — saying you know which corners are load-bearing is. That distinction is the difference between principled speed and reckless haste.