(Image generated by AI)
The Battlefield of Pull Requests
Ah, the Code Review. In theory, it is a harmonious, collaborative process where brilliant minds come together to ensure the highest quality of software.
In practice, it often feels like submitting your finger-painting to an art critic who only responds in passive-aggressive comments like, “Did you consider using a Strategy Pattern here?” or “Please rename dataList to items.”
Why do Pull Requests (PRs) sometimes feel like personal attacks? And why do we frequently miss glaring bugs in our own code before submitting it? The answer lies deeply embedded in human psychology: Cognitive Biases.
A cognitive bias is a systematic error in thinking that occurs when people are processing information. Let’s look at the worst offenders in the software engineering world.
1. The Curse of Knowledge
What it is: The Curse of Knowledge occurs when an individual, communicating with others, unknowingly assumes that the others have the background to understand.
How it ruins Code Reviews: You spent four days deciphering a horrific legacy database schema. You finally write a 50-line script to migrate the data. To you, the logic is crystal clear. You’ve lived and breathed it for 96 hours.
You submit the PR with absolutely zero comments. When a reviewer asks, “What does calculateFactor(73) do?”, you roll your eyes. Isn’t it obvious?!
Spoiler alert: No, it isn’t. You have the Curse of Knowledge. You forgot what it feels like to not know how the system works.
The Fix: Always write your code and PR descriptions assuming the reviewer has just woken up from a 5-year coma. Document the why, not just the what.
2. Confirmation Bias
What it is: The tendency to search for, interpret, favor, and recall information in a way that confirms one’s preexisting beliefs.
How it ruins Code Reviews: You just wrote a brand new REST API endpoint. Because you are a great developer, you test it. You send a valid JSON payload, the server returns a 200 OK, and you confidently declare the feature complete.
You only tested the “Happy Path”—the scenario you believed would work. Your confirmation bias blinded you to the fact that sending a null value crashes the entire server.
A Code Example (From Scratch)
Let’s look at a simple Java example where Confirmation Bias bites us.
public class UserService {
// We want to extract the domain from an email address.
// Example: "john@thoughtstopen.com" -> "thoughtstopen.com"
public String extractDomain(String email) {
int atIndex = email.indexOf('@');
// Developer tests with "test@gmail.com" -> Returns "gmail.com". It works!
// Confirmation Bias says: "Ship it to production!"
return email.substring(atIndex + 1);
}
}
If the developer only tests valid emails, the code looks perfect. But what if the user inputs an invalid string without an @ symbol?
String badInput = "just_a_username";
// email.indexOf('@') returns -1.
// email.substring(-1 + 1) -> email.substring(0)
// It returns "just_a_username" instead of throwing an error or returning null!
The Fix: You need an adversarial mindset. When reviewing code, actively try to destroy it. Ask yourself, “What is the worst possible data a user could throw at this function?”
3. Bikeshedding (The Law of Triviality)
What it is: C. Northcote Parkinson observed that a committee tasked with approving a nuclear power plant will spend 5 minutes on the complex reactor design, but 45 minutes arguing over the color of the staff bike shed. People focus on trivial issues because they are easy to understand.
How it ruins Code Reviews: A developer submits a massive PR containing a complete architectural overhaul of the payment processing system.
Instead of reviewing the complex concurrency handling (which is hard and requires deep thought), the reviewers leave 40 comments arguing about whether to use single quotes or double quotes, and whether a variable should be named paymentManager or paymentHandler.
A massive security flaw slips into production, but hey, at least the variable names are perfectly aligned.
The Fix: Let the robots handle the bike shed. Implement automated linting, code formatting (like Prettier or Checkstyle), and static analysis tools in your CI/CD pipeline. A human should never leave a PR comment about indentation. Save human brainpower for architecture, logic, and security.
Conclusion
We are not perfectly rational coding machines; we are humans writing instructions for rocks that we tricked into thinking with electricity. By acknowledging our cognitive biases—fighting the Curse of Knowledge with documentation, Confirmation Bias with edge-case testing, and Bikeshedding with automation—we can turn Code Reviews back into what they were meant to be: a collaborative effort to build great things.