Elixir supports various ways to debug code: printing with `IO.inspect`, prying with `IEx.pry`, or using more advanced OTP tools like `:debugger` and `:int`. Choosing when to use these different tools can be confusing, and understanding how they work can prove downright intimidating.

Throughout this talk we'll peel back the covers on the more advanced debugging techniques and dissect exactly how each debugging tool can be used to examine our compiled code. None of debugging techniques leave your code the same as how it was running in production. Adding `IO` and `IEx.pry` calls obviously changes the code as you edit the source, but using the OTP debugger, either with `:debugger`, IntelliJ Elixir, or Elixir Language Server, or by adding new `break` points from the `IEx.pry` shell changes the module code being run.

Luke Imhoff will show how each type of debugging changes the code by revealing how `IEx.pry` and `:debugger` are implemented. You'll see why sometimes the debuggers can't reproduce bugs because the modifications to make the code debuggable also subtly changes the execution of the code by looking at changes to the bytecode and AST. Although the modified code never exists as source, we can recover the Abstract Syntax Tree (AST) of either the Elixir quoted form or the Erlang Abstract Code from the Dbgi chunk, but the Dbgi chunk ASTs aren't terribly easy to read, so we can use tools to decompile the code and translate it to Elixir or Erlang modules.

When looking at Dgbi code isn't enough, we can drop down to the Code chunk and look at the bytecode. The bytecode is a unique binary format, so once again we reach for for tools to render it, so instead of having to read machine code, we can read assembly. Looking at this bytecode also allows us to check if our high-level optimizations, such as module attribute reuse, compute variables once, and the order of pattern matching, have an impact on the code run by the VM, as unlike Dbgi, the Code chunk is actually loaded by the VM when running code without debugging.