Every developer has a debugging style. Most of them are slower than they need to be. Here are the techniques worth learning.

1. Conditional breakpoints

Right-click a breakpoint in VS Code → “Edit Breakpoint” → add a condition like user.id === 42. The debugger only stops when that expression is truthy. This is 10× faster than hitting a breakpoint 200 times in a loop.

2. Logpoints (no code changes required)

In VS Code: right-click gutter → “Add Logpoint”. Enter an expression like "user: {user.id}". It prints to the debug console without modifying your source. Your coworkers won’t see a stray console.log in the PR.

3. The debugger statement in production builds

Sometimes you need to break in a deployed app with no source maps. Add debugger; to the source, open DevTools before loading, and the browser will pause there. Remove it before committing. Set up a lint rule to catch it.

4. Watch expressions

Add expressions to the Watch panel (user.permissions.length, response.status). They update on every step. Stop rechecking the same variables manually.

5. console.table for arrays of objects

console.table(users); // renders a sortable table in DevTools

Better than console.log(users) for anything with more than 3 fields.

6. Step Into vs Step Over (actually understand the difference)

• Step Over (F10): runs the current line, doesn’t enter function calls
• Step Into (F11): follows execution into the next function call
• Step Out (Shift+F11): runs to the end of the current function and pauses in the caller

Most devs hammer F10 and miss where the bug actually lives.

7. The Call Stack panel is your friend

When you hit a breakpoint, look at the Call Stack. Click any frame to jump to that context. This is how you answer “how did we get here?” without reading 10 files.

8. Source map tricks

If minified code is your nemesis: DevTools → Settings → “Enable source maps”. For Node, run with --enable-source-maps. If source maps aren’t loading, check that your build config outputs them and your server serves .map files.

9. performance.mark for timing

performance.mark('render-start');
doExpensiveRender();
performance.mark('render-end');
performance.measure('render', 'render-start', 'render-end');
console.log(performance.getEntriesByName('render')[0].duration);

More accurate than console.time and shows up in the Performance panel timeline.

10. Reproduce it in isolation

The best debugging trick: shrink the reproduction. Copy the failing code to a new file, remove everything not related to the bug. You’ll often find the issue just by doing this. When you don’t, you have a minimal repro you can share or post for help.

The single biggest upgrade: switch from “add console.logs until I find it” to “set a breakpoint at the entry point and step through.” It feels slower at first. It’s 3× faster after one week.