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

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 <Project X> and I was curious about it since I think it might help my team with <Project Y>"
​
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 an Expert Code Reviewer! Code reviews continue to be a point of contention in our industry. Some teams have adopted code reviews wholeheartedly... Read more Buy Now!

​

Other Creators I Recommend

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. Subscribe​

Nerd Notes | Power-up your freelancing By Chris Hufnagel Every Tuesday, creative freelancers (like you) learn from my 12+ years out on my own. Pricing, productivity, mindset, and everything in between. Subscribe​

​

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

​

​