Behind the Code: Bridging the Gap Between IDE Logs and Developer Intent

TL;DR

To truly understand how developers work, raw IDE logs aren't enough—we need context. This paper presents a landmark dataset for the Mining Software Repositories (MSR) community: 600+ hours of interaction traces coupled with 26+ hours of "think-aloud" video recordings. By providing the "ground truth" of what a developer was actually thinking and seeing, this dataset enables more robust research into program comprehension and tool development.

The Problem: The "Black Box" of Interaction Logs

Mining developer interaction traces (the sequence of clicks, edits, and scrolls in an IDE) is a standard method for studying software engineering. However, the field has long been plagued by two issues:

1. Data Scarcity: Lack of large-scale, industrial-grade datasets.
2. Contextual Blindness: If a log shows a 10-minute gap after a "File Open" event, was the developer struggling with complex logic, or simply getting a coffee?

Without "ground truth," researchers are often guessing the intent behind the data.

Methodology: Capturing the Developer's Mind

The researchers followed six professional developers for four months as they performed maintenance on Java-based web systems. The data collection was two-pronged:

1. Quantitative: Interaction Traces

Using an Eclipse plugin (Mimec), they captured:

• Kind: Edit, selection, command, or preference.
• Target: The specific Java class or method.
• Origin: Where in the IDE the action happened (e.g., Package Explorer).

2. Qualitative: Think-Aloud Sessions

Developers recorded their screens and narrated their thought processes. This provides the "Why" behind the "What."

Figure 1: The hierarchical structure of the released dataset, organized by developer and task type.

Solving the "Idle Time" Problem

One of the most technical contributions is the author's heuristic for dealing with "Unknown activities outside the IDE." Since Mimec only logs when a developer is in Eclipse, the authors used a lookup table of average task durations to distinguish between actual work (like checking documentation) and idle time (like breaks).

Experiments & Results: A High-Fidelity Resource

The dataset has already been utilized in numerous studies regarding Code Smells and their impact on maintenance effort. By comparing the truncated logs with the video metadata, researchers can achieve a level of triangulation that is rare in software engineering studies.

Table 1: Schema of the Interaction Traces provided in the dataset.

Critical Insight: Why This Matters for the AI Era

In an age where we are building AI coding assistants (like Copilot or Devin), this kind of data is gold. To train models that actually help developers, we don't just need to know what code they wrote; we need to know:

• When they felt confused.
• What parts of the documentation they prioritized.
• How they navigated a legacy codebase before making a change.

Conclusion & Limitations

While the dataset is slightly aged (recorded in the Eclipse era), the core logic of developer behavior remains remarkably consistent. The major limitation is that only ~5% of the total trace hours have accompanying video. However, this sample provides a vital "Rosetta Stone" for interpreting the larger quantitative dataset.

Takeaway: Future software engineering research must move beyond "Big Data" and toward "Thick Data"—data that combines scale with deep contextual meaning.