An Eye for Trust: An Exploration of Developers' Trust Perceptions Through Urgency and Reputation
This study utilizes eye-tracking data from a controlled experiment to reveal that while urgency and reputation significantly influence developers' code review behaviors and visual attention patterns, these factors do not ultimately affect their decisions to implement code or their self-reported awareness of such influences.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are a manager at a busy construction site. Every day, workers (developers) bring you blueprints (code patches) to fix small problems in a building. Your job is to decide: "Is this fix good enough to use, or should I send it back?"
Usually, you'd look strictly at the blueprint itself. But this paper asks a fascinating question: Do you subconsciously change how you look at the blueprint based on two things you shouldn't really care about?
- The Urgency: Is this a "CRITICAL, BUILDING IS ON FIRE" fix, or a "Let's fix this when we have coffee" fix?
- The Reputation: Did the blueprint come from "Master Builder Bob" (Senior) or "Apprentice Billy" (Junior)?
The researchers, Sara Yabesi and her team, wanted to find out if these two factors change how developers think and look at code, even if they don't realize it. To do this, they didn't just ask people what they thought; they put glasses with tiny cameras on 37 developers to track exactly where their eyes moved.
Here is the breakdown of their findings, translated into everyday language:
1. The "Fire Drill" Effect (Urgency)
When the researchers told the developers, "This patch is High Priority (The building is on fire!)," something interesting happened:
- The Eyes: The developers' eyes moved differently. They spent more time staring at the specific test results and the code itself. It was like they were putting on a magnifying glass and reading every single word. Their brains were working harder (higher "cognitive load").
- The Verdict: Even though they looked harder and thought the code was "better quality" just because it was labeled urgent, they didn't actually accept or reject the code more often. They still judged the code on its own merits.
- The Catch: The developers thought they were being objective. When asked later, they said, "Urgency didn't change my mind." But their eyes told a different story: they were definitely more stressed and focused when they thought the building was on fire.
Analogy: It's like a doctor looking at an X-ray. If the nurse whispers, "This is a critical patient," the doctor might stare at the X-ray longer and squint harder, even if the X-ray itself hasn't changed. The doctor thinks they are being thorough, but the "urgency" made them look differently.
2. The "Name-Tag" Effect (Reputation)
Next, they told the developers who wrote the code. One group was told it was written by a Senior Developer (a veteran), and the other by a Junior Developer (a newbie).
- The Eyes: Again, the eyes moved differently. When they thought a "Senior" wrote it, they focused more on the specific methods (the logic). When they thought a "Junior" wrote it, their scanning pattern changed slightly.
- The Verdict: Surprisingly, this didn't change their final decision at all. They accepted or rejected the code at the exact same rate, regardless of who they thought wrote it. They also didn't rate the "Senior" code as better quality.
- The Catch: Just like with urgency, the developers claimed, "The author's name didn't matter." But their eyes showed they were treating the "Senior" code with a slightly different kind of attention.
Analogy: Imagine you are tasting soup. If you are told it was made by a famous chef, you might swirl it around the spoon a bit differently, savoring it more. But if you are told it was made by a student, you might just take a quick sip. In the end, you might still decide the soup tastes the same, but your experience of tasting it was different.
3. What Actually Matters?
When the researchers asked the developers, "What factors actually influenced your decision?" the answers were boring but honest:
- Does it work? (Functionality)
- Is it easy to read? (Quality/Readability)
- Do the comments make sense? (Comprehensibility)
The developers genuinely believed they were ignoring the "Urgency" and the "Author's Name." They thought they were purely logical robots.
The Big Takeaway
The most surprising part of this study is the gap between what people say and what their eyes do.
- What they said: "I am a fair judge. I look at the code, not the label."
- What their eyes showed: "I am subconsciously stressed by urgency and I scan differently based on who I think wrote this."
Why does this matter?
In the real world, we rely on code reuse and AI tools (like GitHub Copilot). If we don't realize that "Urgency" makes us over-analyze or that "Reputation" changes how we scan code, we might miss bugs or accept bad code just because we were in a rush or trusted a "famous" name too much.
The researchers suggest that our tools and guidelines need to help developers realize these hidden biases. We need to build "mirrors" that show us when we are letting urgency or reputation cloud our judgment, so we can make better, safer software.
In a nutshell: We like to think we are logical scientists, but when it comes to code, our eyes betray us. We get stressed by "fires" and scan differently based on "famous names," even when we swear we aren't.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.