Debugging Reference

Overview

This reference captures the fastest order of operations when the app is broken.

Why It Matters

Debugging gets much faster when you keep the investigation order consistent.

Core Concepts

• Check the browser console.
• Check the network tab.
• Check the boundary that owns the failure.

Mental Models

Work from the outside in: user experience, network, auth, backend, database, and infrastructure.

Best Practices

• Reproduce the issue.
• Change one thing at a time.
• Verify the full flow after fixing.

Common Mistakes

• Jumping between layers with no plan.
• Fixing the symptom instead of the cause.
• Forgetting to check the actual request or response.

Trade-offs

A disciplined order feels slower at first, but it usually beats random exploration.

Decision Framework

flowchart TD
  A[Bug] --> B[Console]
  B --> C[Network]
  C --> D[UI state]
  D --> E[Auth]
  E --> F[Backend]
  F --> G[DB / Infra]

Examples

• 200 plus broken UI usually means the bug is in render or state.
• 401 usually means auth/session.
• 500 usually means server logs.

Checklists

• Can I reproduce it?
• Do I know the failing layer?
• Did I confirm the fix?

Senior Engineer Notes

Senior engineers do the same first few steps every time because consistency beats memory under pressure.

Further Reading

• Debugging
• HTTP Error Codes
• Production Incidents