Debugging is mental model building, not tool use

A Grounded Theory of Debugging in Professional Software Engineering Practice

Debugging is a central yet complex activity in software engineering. Prior studies have documented debugging strategies and tool usage, but little theory explains how experienced developers reason about bugs in large, real-world codebases. We conducted a qualitative study using a grounded theory approach. We observed seven professional developers and five professional live-coding streamers working on 17 debugging tasks in their own codebases, capturing diverse contexts of debugging. We theorize debugging as a structured, iterative diagnostic process in which programmers update a mental model of the system to guide information gathering. Developers gather information by alternating between navigation and execution strategies, employing forward and backward tracing modes of reasoning and adapting these approaches according to codebase context, complexity, and familiarity. Developers also gather external resources to complement code-based evidence, with their experience enabling them to systematically construct a mental model. We contribute a grounded theory of professional debugging that surfaces the human-centered dimensions of the practice, with implications for tool design and software engineering education.

arxiv.org

A paper by Haolin Li and Michael Coblenz, which won a distinguished paper award at the Foundations of Software Engineering conference this month, did something unusual: it watched professional developers debug their own code. Seven working developers and five professional live-coding streamers, seventeen real debugging tasks, in codebases they actually maintain.

The picture that emerges is not about tools. Debugging, in the authors' description, is a structured, iterative process in which the developer updates a mental model of the system and uses it to decide what information to gather next. They switch between navigating code and executing it, between tracing forward from a cause and backward from a symptom, and which strategy they reach for depends on the codebase and on how well they know it.

The sentence I keep coming back to is the one about familiarity. The developers were fast because they had a model of the system already, built over months of working in it. Drop the same person into an unfamiliar service and the model is gone, and so is most of the speed.

I think that has a direct management consequence. A team's debugging capacity lives in codebase familiarity, which is slow to build and easy to destroy. Rotating people across services every quarter, or handing on-call to whoever is awake rather than whoever knows the system, spends that capacity.

When something breaks at 3am, does the person who gets paged know the system, or just the runbook?

Photo source: https://photos.robertstowe.com/tasmania