Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Kevin Lubick

dblp:155/7992 · DBLP profile ↗
← Back
4ranked-venue papers
0as first author
0since 2021 · last 2017
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 4Databases, data management, data science and information retrieval · 1Human-computer interaction and ubiquitous computing · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
2 papers
Empirical software engineering · 49% Software maintenance and evolution · 43% Software testing · 7%

Topics — the 4 heaviest of 5, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Empirical software engineering
developer studies
0.312017
Do developers read compiler error messages? · ICSE 2017
Empirical software engineering › human factors in software engineering
eye-tracking studies
0.312017
Do developers read compiler error messages? · ICSE 2017
Software maintenance and evolution
program comprehension
0.312017
Do developers read compiler error messages? · ICSE 2017
Software maintenance and evolution › software configuration management
version control
0.212015
Commit Bubbles · ICSE (2) 2015

Methods — techniques the papers use, named apart from their topics

eye tracking · 0.3
YearPublicationVenuePosition
2017 Do developers read compiler error messages?
abstract
In integrated development environments, developers receive compiler error messages through a variety of textual and visual mechanisms, such as popups and wavy red underlines. Although error messages are the primary means of communicating defects to developers, researchers have a limited understanding on how developers actually use these messages to resolve defects. To understand how developers use error messages, we conducted an eye tracking study with 56 participants from undergraduate and graduate software engineering courses at our university. The participants attempted to resolve common, yet problematic defects in a Java code base within the Eclipse development environment. We found that: 1) participants read error messages and the difficulty of reading these messages is comparable to the difficulty of reading source code, 2) difficulty reading error messages significantly predicts participants' task performance, and 3) participants allocate a substantial portion of their total task to reading error messages (13%-25%). The results of our study offer empirical justification for the need to improve compiler error messages for developers.
Titus Barik, Justin Smith 0001, Kevin Lubick, Elisabeth Holmes, Jing Feng 0004, Emerson R. Murphy-Hill, Chris Parnin
ICSE3
2015 Commit Bubbles
abstract
Developers who use version control are expected to produce systematic commit histories that show well-defined steps with logical forward progress. Existing version control tools assume that developers also write code systematically. Unfortunately, the process by which developers write source code is often evolutionary, or as-needed, rather than systematic. Our contribution is a fragment-oriented concept called Commit Bubbles that will allow developers to construct systematic commit histories that adhere to version control best practices with less cognitive effort, and in a way that integrates with their as-needed coding workflows.
Titus Barik, Kevin Lubick, Emerson R. Murphy-Hill
ICSE (2)2
2015 Fuse: A Reproducible, Extendable, Internet-Scale Corpus of Spreadsheets
abstract
Spreadsheets are perhaps the most ubiquitous form of end-user programming software. This paper describes a corpus, called Fuse, containing 2,127,284 URLs that return spreadsheets (and their HTTP server responses), and 249,376 unique spreadsheets, contained within a public web archive of over 26.83 billion pages. Obtained using nearly 60,000 hours of computation, the resulting corpus exhibits several useful properties over prior spreadsheet corpora, including reproducibility and extendability. Our corpus is unencumbered by any license agreements, available to all, and intended for wide usage by end-user software engineering researchers. In this paper, we detail the data and the spreadsheet extraction process, describe the data schema, and discuss the trade-offs of Fuse with other corpora.
Titus Barik, Kevin Lubick, Justin Smith 0001, John Slankas, Emerson R. Murphy-Hill
MSR2
2014 How Developers Visualize Compiler Messages: A Foundational Approach to Notification Construction
abstract
Self-explanation is one cognitive strategy through which developers comprehend error notifications. Self-explanation, when left solely to developers, can result in a significant loss of productivity because humans are imperfect and bounded in their cognitive abilities. We argue that modern IDEs offer limited visual affordances for aiding developers with self-explanation, because compilers do not reveal their reasoning about the causes of errors to the developer. The contribution of our paper is a foundational set of visual annotations that aid developers in better comprehending error messages when compilers expose their internal reasoning. We demonstrate through a user study of 28 undergraduate Software Engineering students that our annotations align with the way in which developers self-explain error notifications. We show that these annotations allow developers to give significantly better self-explanations when compared against today's dominant visualization paradigm, and that better self-explanations yield better mental models of notifications. The results of our work suggest that the diagrammatic techniques developers use to explain problems can serve as an effective foundation for how IDEs should visually communicate to developers.
Titus Barik, Kevin Lubick, Samuel Christie, Emerson R. Murphy-Hill
VISSOFT2