Debuggingmedium3-5 years
A program that used to work now crashes somewhere in a thousand-line file, and nobody knows which recent change broke it. Someone suggests reading the whole file top to bottom to find the bug. Why is that the slow way, and what would a faster method look like?
Reading everything is linear — a thousand-line file means up to a thousand things to check. The faster method is bisection: find a point you know is correct (the start, or a version before the change) and a point you know is wrong (the crash), then check the middle. Whichever half is still correct, the bug is in the other half — and you just eliminated half the file with one observation. Repeat on the remaining half, and about ten checks (since 2^10 is roughly 1000) narrow a thousand lines down to one, because halving is logarithmic — it barely grows even as the file gets much bigger. It works without understanding the code at all; you're just asking 'is the state still right here?' at each checkpoint.
PreviousA mobile client times out waiting for a response to `POST /api/orders`, so it automatically retries the exact same request. What could go wrong, and would the same retry be safe for `PUT /api/orders/42`?Next A payment API returns `{"amountPaid": 19.99, "amountDue": 19.99}`. Both values print as `19.99` after being parsed into Java `double`s, but `amountPaid.equals(amountDue)` sometimes returns `false`. How can two values that print identically compare as unequal, and what's the actual fix?