Debugging is a method, not a talent. Reproduce the problem, read the actual error, form one hypothesis, test it, and narrow the search until the cause has nowhere left to hide. Give yourself a fixed window of honest effort before asking, and when you do ask AI or a person, bring your evidence so you still learn from the answer.
What people tell me
Whenever something breaks, I paste the error into ChatGPT or message a senior developer within a few minutes. It usually works, but I have noticed I cannot fix things on my own, and I do not really understand why the fixes work. When I try to debug alone, I change random things and hope something helps. I want to become someone who can actually find and fix problems.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Always reproduce the bug first. If you cannot make it happen reliably, you cannot know when it is fixed.
- Read the whole error and stack trace. The answer is in there more often than people think.
- Change one thing at a time, based on a hypothesis you can say out loud.
- Set a time box, for example thirty to sixty minutes, before asking for help. Then ask with evidence.
- After every fix, write one line about the cause. That log becomes your pattern library.
Why this matters more than it seems
When AI tools can suggest a fix for almost any error, it is tempting to think debugging skill no longer matters. In my experience it matters more. AI is good at common errors with clear messages. Real bugs at work are rarely like that: they involve your data, your configuration, your services talking to each other in ways no tool has seen. The engineers people rely on are the ones who can find the cause when there is no obvious answer to paste.
The good news is that debugging is a method. You can learn it the same way you learn any other procedure.
The method
Follow these steps in order, every time, until they are automatic:
- Reproduce it. Find the exact steps, input or request that makes it fail. Write them down.
- Read the error properly. The full message, the full stack trace, and the first line that points to your own code rather than a library.
- State what you expected versus what happened. One sentence each. This alone solves a surprising number of bugs.
- Form one hypothesis. "I think the user object is empty because the request finishes before the fetch completes."
- Test that hypothesis only. Add a log, set a breakpoint, or check the value. Do not change three things at once.
- Narrow the search. If the value is correct here but wrong there, the bug lives in between. Halve the space until it has nowhere to hide.
- Fix, then confirm with your reproduction steps. Then ask whether the same cause exists anywhere else.
Changing random things and hoping is the opposite of this. It sometimes works, but you learn nothing and often create a second bug.
Tools worth learning properly
You do not need many, but you need to be comfortable with them:
| Tool | Why it helps |
|---|---|
| The debugger in your editor | Pause at a line and inspect every variable instead of guessing |
| Browser developer tools | Network tab, console and application storage explain most frontend bugs |
| Logs with context | A log that includes the IDs and values involved is worth ten that say "error" |
| Git history and git bisect | Find exactly which change introduced a bug |
| Reading the library source | When documentation is unclear, the code is the truth |
Spend an hour learning your editor's debugger deliberately. It is one of the highest-return hours you will ever spend.
Use a time box, not willpower
Telling yourself "never ask" does not work, and it is not the goal. Being stuck for a whole day on something a colleague could explain in two minutes is also a waste. Use a rule:
- Spend thirty to sixty minutes following the method honestly.
- If you are still stuck, ask, and bring what you learned.
A good question looks like this:
The checkout request returns 500 only for users with saved cards. I reproduced it locally. The error is a null reference in the price calculation, and I confirmed the card object is present but the currency field is missing. I think the migration from last week did not backfill it. Does that sound right, or is there another place currency is set?
That message shows the work, makes the answer quick, and means you learn from the reply instead of just receiving a fix.
Using AI without handing over your brain
AI is a legitimate debugging partner if you use it the way you would use a colleague:
- Give it your hypothesis and ask it to challenge it, rather than asking it to fix the code.
- Ask it to explain an unfamiliar error message or library behaviour, then verify in the docs.
- Never paste a fix you cannot explain. If you cannot say why it works, you have not finished debugging.
Build a pattern library
Every senior engineer carries a mental list of "I have seen this before". You can build yours on purpose. After every non-trivial bug, write one line in a notes file: symptom, cause, how you found it. For example: "Form submits twice. Cause: event listener added on every render. Found by logging listener count." After six months, you will be surprised how often you recognise a new bug from an old line.
A two-week practice plan
- Pick one of your own projects and deliberately break something small each day, then fix it using only the method and the debugger.
- Read three closed bug reports in an open source project you use and follow how the cause was found.
- For every bug at work or in your projects, write the one-line note.
If you are still stuck
Read How to Use AI as a Companion, Not a Crutch, Sixteen Things That Break a Backend, and What Prevents Each and Git, Properly: The Model Behind the Commands. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- How to Use AI as a Companion, Not a CrutchOne rule decides whether AI tools make you faster or hollow you out: use them for work you could do yourself but would rather not, and for work you are actively trying to understand, never for work you cannot evaluate. Where they genuinely excel, where they quietly damage your skills, and the verification habits that separate engineers who benefit from those who accumulate debt.
- Sixteen Things That Break a Backend, and What Prevents EachBackend engineering is taught as frameworks and turns out to be almost entirely about what happens when the database is slow, when the same request arrives twice, or when a downstream service stops answering without saying so. None of it is deep, all of it is invisible until it happens to you at an unpleasant hour. Sixteen situations and their usual answers.
- Git, Properly: The Model Behind the Commands You Use Every DayMost people learn Git as a list of commands and get stuck the first time one does something unexpected. The model underneath is small: three places your code lives, commits as snapshots, branches as pointers. Learn that, and the everyday commands, the traps in stash and pull, and the safe ways to undo a mistake all make sense.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.