Repro the bug report: long URLs blowing out a card

Reading a bug report like an engineer

When you're new, "the layout is broken" feels overwhelming. Senior engineers do something specific: they reproduce the bug locally first, in the smallest possible code, before touching the actual codebase. This is the single highest-leverage habit you can build.

This lesson teaches it in two steps.

Step 1 — reproduce. You're handed a real-shape bug report. Your job: write the smallest HTML + CSS that triggers the same visual problem. You're not fixing anything yet. You're making the bug *show up on your screen*.

Step 2 — fix. Once your repro shows the bug, you'll get the standard fix task and the broken starter the rest of the team is staring at. Now you fix it.

Why this order matters

• If you can't repro, you can't verify a fix. You might "fix" something that wasn't broken and ship a bug that still exists.
• Repro forces you to read the bug report carefully — what device, what content, what action. Junior devs skip this and start grep-ing the codebase blind.
• The minimal repro often IS the bug. Once you have 20 lines of HTML that show it, the cause is usually staring at you.

The actual content rule today

A common bug pattern: a card layout that looks fine with short text breaks on the right edge when content has a long unbreakable token — a URL, a hash, a German compound word. Fixed-width cards leak; the container overflows the screen; a horizontal scrollbar appears on mobile.

The fix is one CSS property. But first — reproduce the bug.