GuideAdvanced
Debugging and Troubleshooting
Take an unknown failure — a thirty-line traceback, a silently wrong result, a regression buried under two hundred commits, or a test that fails once every thirty runs — and learn to reproduce it, corner it down to the exact line, and explain it with evidence, before asking a model anything; and when you do ask, learn to verify whether the answer is correct. The six modules move from reading the failure (what a traceback is already telling you) to the method that goes from symptom to root cause, to the debugger for stopping the program and looking inside, to logging for diagnosing what already happened, to bisection for cornering regressions and intermittent failures, and close with AI in the loop: using it after you understand the error, not instead of understanding it. The final project is a debugging dossier on a repository with five failures of different natures — including a regression that requires `git bisect run` — resolved with protocol, evidence, and a regression test.
- 48
- lessons
- 6
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Read a complete Python traceback — including a chained one or one from async code — and pinpoint the file, the line, and the culprit frame in your own code
- Tell the symptom apart from the root cause, reproduce a bug reliably, and reduce it to a minimal reproducible example (MRE)
- Formulate falsifiable hypotheses and recognize the reasoning biases that stretch out a debugging session: confirmation bias, "shotgun debugging", dead ends
- Use a debugger — `pdb` and a graphical debugger like `debugpy` — to stop execution exactly where your hypothesis points, instead of printing blindly
- Instrument with `logging` (levels, context, exceptions with a full traceback) to diagnose failures that already happened and that you can't reproduce live
- Apply bisection — `git bisect`, isolation by layer and by data — to find the exact commit or condition that broke something
- Turn an intermittent failure into a deterministic one by fixing seeds, time, execution order, or shared state
- Run a verifiable protocol before asking a model for help, and verify its answer by reproducing the failure instead of applying the patch blindly
- Close a bug with a root-cause postmortem and a regression test, not just with the symptom resolved
Before you start
What you need to bring
It's for you if...
- Devs who paste a traceback into a model without having read it first, and want to break that habit
- Devs who only debug with `print()` and want to master a real debugger: `pdb`, `debugpy`
- Teams dealing with intermittent bugs, regressions buried in commit history, or failures that only happen in production
- Anyone who wants to use AI to debug without falling into the "patch, new error, patch, new error" loop
Requirements and materials
- Python at the level of functions, modules, and exceptions (`try/except`), and virtual environments
- Basic Git: `commit`, `log`, `checkout` — no need for `bisect`, it's taught in the guide
- Running scripts and commands from the terminal
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Introduction: the error already carries half the answer
- 2. The copy-paste reflex: what you lose when the model answers first
- 3. What a call stack really is
- 4. Walking a full traceback, line by line
- 5. Your code versus library code: where the border is
- 6. Chained exceptions: following the chain to the origin
- 7. Exception dictionary: what cause hides behind each one
- 8. Project: triaging real tracebacks
- 1. Introduction: when the program doesn't crash, it just gets it wrong
- 2. Symptom and cause: the distinction that decides whether the bug comes back
- 3. Reproduce before you fix
- 4. The hypothesis loop: debugging as an experiment
- 5. The minimal reproducible example
- 6. Biases, dead ends, and when to stop
- 7. The same method outside Python: browser, HTTP, and containers
- 8. Project: from a vague report to a root-cause report
- 1. Introduction: stop assuming and start looking
- 2. Debugging with print: when it's enough and when it gets in the way
- 3. Your first breakpoint with pdb
- 4. pdb's vocabulary: moving around and viewing state
- 5. Traversal strategy: where to stop and how deep to go
- 6. Conditional breakpoints and post-mortem autopsy
- 7. Graphical debugging with debugpy in VS Code and Cursor
- 8. Project: hunting a silent bug with the debugger
- 1. Introduction: debugging what already happened
- 2. From print to the logging module
- 3. Levels: the criterion for what goes in each one
- 4. Logging exceptions without destroying the evidence
- 5. Logs with context: from a loose sentence to a queryable record
- 6. Designing logs you can debug with
- 7. From logs to a failure's timeline
- 8. Project: instrumenting a service that sometimes fails
- 1. Introduction: when no single clue is enough
- 2. Bisection as a mental model
- 3. git bisect: finding the commit that broke everything
- 4. Isolating by layer and by data
- 5. "It works on my machine": environment and dependencies
- 6. Intermittent failures: making the non-deterministic deterministic
- 7. When "failing" means slow or out of memory
- 8. Project: finding the commit that broke the suite
- 1. Introduction: AI is a good second step
- 2. What to do before you paste the error
- 3. Asking for help the right way: a model and a human
- 4. Verifying the answer: hypothesis, not patch
- 5. Signs that AI is making the problem worse
- 6. Debugging code no human wrote
- 7. The postmortem: closing the bug for real
- 8. Final project: debugging dossier
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!