What is Clairvoyance in Code Reviews?


Team-Driven Developer

A newsletter with tips and tools for building software as a team

A few weeks ago, I co-authored an article with some friends at Greptile about AI vs. human code reviews. It was a blast working with Greptile’s co-founder, Daksh, on the article, as he brings an insider perspective about the new AI technology helping software developers become increasingly effective at their craft.

One of our key points was around something that was likely unexpected to a reader: the idea of clairvoyance. In our article, we claimed

With enough experience, some engineers can predict a change being painful 6 months down the line in a way that isn’t clear yet to most people.

And while the concept of clairvoyance goes beyond simple predictions about what will happen within a codebase, some of the readers of this blog might have raised an eyebrow. “Dan, haven’t you always advocated for not trying to predict too much about the code review?”

You’d be right to think so. I’ve authored many articles on this topic, including one literally titled “Stop Predicting the Future of Your Code”

In today’s article, I want to reconcile this contradiction. I’ll explain a bit more about what I mean by being clairvoyant as an engineer regarding code and why the most clairvoyant engineers are often those advocating for the simplest code to complete the task at hand.


Team-Building Exercise

This week's team-building exercise is a bit divergent from the article itself but more focused on how the article came to be: collaboration.

I'm a big fan of collaborating with your team rather than just cooperating (though sometimes that is all you can do).

But it's also important to collaborate with people outside of your immediate team or even company!

When it comes to building a software team, you have to have both a team-focused lens (how can I help my team succeed?) and an organization-focused lens (what is the whole org working on and how can I help?). It's hard to have that second lens if you have weak relationships with those outside of your team.

This week, focus on building some relationships with colleagues on teams that are different from yours. It can be a bit scary, but few people are so standoffish they won't be willing to answer a few questions you have about their work and how you could help!

A playbook I've used before is this: "Hey so and so, I saw you were working on

You, of course, need to actually be curious, and there should be a real need for knowledge sharing; faking it won't go well. But it is easier than you might think once you put on a curious mindset to learn what others are working on in the org.

Go slow, too. The goal isn't to start leveraging someone to get your work on their backlog or anything like that. The goal is to genuinely meet new people and build relationships.

Who knows - you might write even co-write an article together or work on a project together!


Here are some more resources from me to help you build better teams!​

$14.00

Become awesome at code reviews

Code reviews can be frustrating.
Conflict can arise, reviews can be slow, or reviewers might be too intimidated to... Read more

  • 📕 Code Review Champion - My book on code reviews will help you become a world-class code reviewer. From giving kind feedback to navigating conflict, this book can help anyone wanting to sharpen their code review skills.
  • ❓​Questions for Devs - Building a team takes more than catching up about your weekend at standup. I've used these questions to build relationships with my team and push past the same old surface-level conversations.
  • ​📋 Pull Request Template - Maximize your efforts in pull requests by giving context right at the beginning of a new pull request. Copy and paste this template into your repo, and voilà!
  • 📊 ​Code Review Metrics - Start measuring how your team tracks against a few common code review metrics. This python script will pull your GitHub pull requests and generate a CSV you can slice-n-dice to get the data you want. It also has graphs! As this is an open-source project, your contributions and feedback would be great!

Other Creators I Recommend

Image for Daniel Schaefer

Daniel Schaefer

Subscribe if you are a software developer that has the technical skills, but you're looking for opportunities to enhance your soft skills to advance in your career.

Image for NerdNotes | Learn. Build. Ship.

NerdNotes | Learn. Build. Ship.

By Chris Hufnagel

Join readers of Build Log gaining an edge on their own indie maker adventure. The wisdom, tips, and inspiration you need for your own product building journey.

113 Cherry St #92768, Seattle, WA 98104
Unsubscribe · Preferences

Dan Goslen | The Team-Driven Developer

Learn the tips and tools for building software as a team! Every other week, I send a long-form article, a team-building exercise, and resources to help you build better software teams so you can build better software.

Read more from Dan Goslen | The Team-Driven Developer

Team-Driven Developer A newsletter with tips and tools for building software as a team You’re staring at your editor. The code should work, but you’ve been fighting an error for a full day. You can’t figure out the problem no matter what you try. Or you’ve been staring at an empty file, wondering what code to write. You’ve got a vague Jira ticket, a lack of context, and a codebase that is difficult to understand. You’re blocked. Now, what do you do? It’s tempting—easy, even—to ping someone...

Team-Driven Developer A newsletter with tips and tools for building software as a team Imagine reading a technical design document or RFC. As you read, you notice that the language in the document is a bit confusing. For example: Requests likely need to be authorized using standard HTTP auth mechanisms What does this “requirement” mean? Are we using “standard” Authorization headers with base 64 encoded usernames and passwords? I don’t see a mention of HTTPS. And I also don’t know what...

Team-Driven Developer A newsletter with tips and tools for building software as a team A complex system is not the same as a system that delivers advanced functionality. Complexity within software refers to the characteristics of a software system and its ability to change over time. Functionality refers to the capabilities a software system exposes. In my experience, we often overlook this distinction more than we realize. I’ve seen engineers brag about how complex their system was as...