Why Kolo

Kolo was built by the team behind Simple Poll for Slack who were frustrated with the limitations of traditional debuggers for understanding code.

How is Kolo different from a regular debugger?

Regular debuggers can be powerful tools. When you’re digging into a specific exception or you know exactly where to look, they can be very effective at quickly showing you what you need to know. But they also have their downsides. For starters, they can be tricky to set up and use compared to the simplicity of a print(my_variable).

Once set up and configured, debuggers ask quite a lot of you! They ask you where you’d like to set breakpoints, but you might not even know where you’d like to set them!

Debuggers can be unhelpful in certain cases, and downright frustrating in others:

• Debuggers don’t help when it’s not clear where a breakpoint should be set

• When a specific breakpoint is not getting hit, debuggers don’t tell you why it wasn’t hit (and what happened instead)

• If you want to know what happened before a breakpoint, you’re out of luck

• If you want to know what happened after a breakpoint you have to slowly and carefully step through your code using the debugger’s interface

• Debuggers can help you gather context for a specific point during the code execution, but they aren’t great at giving you an overview of everything that happened. If you don’t know exactly what you’re looking for and where to find it, debuggers can be surprisingly unhelpful

• If you make a mistake with using the often confusing debugger interface of weirdly shaped arrows, then you need to start all over and hopefully do the right thing this time around

Kolo addresses all of the above. You never need to set any breakpoints. All you need to do is have your Django app serve a request, and then you can start exploring. Go up and down the stack as you please and inspect arguments, return values and local variables for all the code that was executed. All right next to your code inside of VSCode.