How to fix a bug in a codebase you didn't write
Most of a developer's first year goes into code that someone else wrote. You won't understand all of it, and you don't need to. This guide is a repeatable process for getting from a bug report to a merged fix, with examples from real Kadra tickets.
1. Read the ticket for its acceptance criteria
The description tells you what's wrong. The acceptance criteria tell you when you're done. Kadra's ECOM-141 ticket has both:
- Description: checkout calculates sales tax on the pre-discount subtotal, so discounted orders are overcharged tax.
- Acceptance: tax is calculated on the discounted subtotal (after coupons).
- Acceptance: orders without a discount are unaffected.
2. Reproduce it before you change anything
Turn the first acceptance criterion into a failing test or a script you can run. ECOM-114's criterion is already a test case: a 10% coupon on a $200 cart should give a $20 discount. If your test passes before you've changed the code, you're looking at the wrong code.
3. Find the code path
Search the codebase for words from the ticket. For ECOM-141 that's "tax" and "discount". Find where the checkout total is computed, then follow the calls outward until you can see the order things happen in.
Read the existing tests for that file. They show how the code is meant to be called and which edge cases someone already thought about.
4. Look for an order-of-operations bug
Many real bugs are two correct steps in the wrong order. ECOM-141 applies tax before the discount instead of after. LEDG-215, in a Python payments service, never checked whether a transfer had already been processed, so a retried request moved the money twice. Where the new check goes matters too. It has to run before the balance check, or a retry on a drained account fails instead of returning the recorded result. The reviewer on that fix called out exactly this:
“placing the transfer_id in processed short-circuit before the balance check is exactly right”5. Make the smallest change that fixes the cause
Resist the urge to tidy up nearby code. A small diff is easier to review and less likely to break something you don't understand yet. The ECOM-114 fix changed one line, and the reviewer noted that it left the fixed-amount coupon path untouched.
6. Prove it, then write it up
Run your reproduction test and the existing suite. Then check every acceptance criterion, including the "unaffected" ones, since those are the regressions a reviewer worries about.
In the pull request, say what was wrong, why, and how you verified the fix. A reviewer who understands the cause from your description approves faster.
Questions people ask
How do I understand a large codebase quickly?
Don't try to understand all of it. Start from the behavior in the ticket, find the one code path that produces it, and read only what that path touches. The rest can wait until a ticket needs it.
What if I can't reproduce the bug?
Check that you're running the same version and data as the report, then ask. On a team, a short message with what you tried is normal and saves hours. In Kadra, each ticket has a teammate you can ask for a hint.
Where can I practice fixing bugs in real code?
Kadra has eight practice tracks, each a working codebase with planted bugs, in Next.js, TypeScript, Python, FastAPI, Go, Java and C#. You fix them on GitHub, and hidden tests grade the result.
Try it on a real ticket
Pick a stack, fix a bug in a working codebase and get your pull request reviewed. Free during beta.