Engineers learn the hard way that when production breaks after a deploy, proving your change isn’t at fault wastes precious time. The first move should be a rollback. Only after you’ve stabilized should you dig into logs, traces, and code diffs. Backed-out code isn’t an admission of defeat—it buys you breathing room to debug the real culprit. Backups are only as good as your last test restore. Have you actually clicked through the restore process on your managed database? Do you know if you have incremental snapshots or only full backups? Who has permission to run the restore, and how long will it take? Infrastructure and data volume shift over time; a restore that took ten minutes six months ago could drag on for hours now. Treat a dry run like mission-critical work. Logging feels like a solved problem until an incident hits. You either under-log, missing key IDs and timestamps, or over-log with gigantic JSON blobs that choke your search. The trick lies in capturing enough context—request IDs, user actions, error codes—without dumping every object in memory. Agree on a shared format and practice searching before you need it. Every third-party API you depend on will fail. Hitting rate limits once turned a weekend into a two-week firefight. Always ask the hard questions: What are their rate limits? What SLA do they promise? Have you tested your feature under simulated API downtime? Can you queue requests or serve stale data? Map out who you call when they break. And if there’s any doubt about a change—DB migration, infrastructure tweak, or dangerous script—get a second pair of eyes. Four eyes catch twice as many slip-ups. Finally, recognize that “temporary” fixes often stick around forever. If you’re building an MVP or patching a hot path, aim for clean simplicity rather than duct tape. That way, if it becomes permanent, you won’t cringe every time you revisit the code.