This talk was part of Developer Growth Summit 2022. Go to the DGS2022 page to view recordings of all sessions.
About the talk
Debugging takes 30-60% of a developer's time. In this talk, we’ll explore how to reduce that and make it more fun. Through Dbux, we'll interact with call graphs, visualize asynchrony, follow the data flow trail, and more.
This talk will cover
- The pain of dynamic program analysis and debugging
- How to alleviate that pain
- A glimpse of what's to come: live demos and examples with Dbux
About the speaker
In love w/ programming for 20+ years. Currently working on building new tools for debugging, visualizing and making interactive the hidden execution behavior of JavaScript applications (as part of my Ph.D. dissertation).
Highlights of the talk
How do we usually debug?
There are a lot of bugs that are easy to fix, but difficult to find. What makes them difficult to find? Debugging is a search problem. You are trying to find one or two bugs in tens of thousands of lines of code, which is like searching for a needle in the haystack. Another way of looking at it, it’s basically a complicated factory and we’re looking at the factory from the outside without understanding how the factory is running. As developers debug, they look at the output of the factory and try to determine what’s wrong with the factory. Which is like a fax machine that is linked to the sensors, which is what console.log/printf, print statements are.
Another way to debug is to essentially stare at the source code or use a traditional debugger. The problem is that the dynamic runtime behavior is not your code, or the other way around. The code is not all things that really matter to developers, as the dynamic runtime behaviors are almost invisible and intangible.
There is a lack of a debugging culture, where professional developers spend time talking about how to make debugging easier. Think about how much time and energy you spend on debugging versus talking about debugging strategy or debuggability. We do talk about testing, but you still need to talk about debugging, dynamic analysis, learning how to debug, and improving debugging skill.
What is an interactive debugger? And what is dynamic analysis?
There are three types of debuggers: automatic, semi-automatic, and interactive. What is a good interactive debugger? If your problem is a needle in a haystack, a metal detector or a magnet would be a good tool. A “good interactive debugger” helps illuminate the dark matter of debugging, all these things that are going on in your program that you don’t know about unless you specifically query every part of your code to give you an answer one step at a time. What you want is to make the dynamic runtime behavior more visual, interactive, and make it easier on your brain to build the mental model.
How does an interactive debugger work? You have the source code, a system you want to run it on, and run it and load it into some process, and you have an application that’s running. And then there’s the debugger backend that uses a control module to start, start, and break and step through it. The application can send you all kinds of data and put those into a data repository with a dynamic analysis engine, and then you can ask the dynamic analysis engine to give you all the information you need regarding your code. The debugger frontend would have visualization and user interaction features.
Awesome debuggers don’t necessarily have to have a strong dynamic analysis engine. You can look at collaborative debugging features (e.g. Replay), and work on CI ←→ debugger integration.