Developing a Growth Mindset Culture Through Code Review

We used to think that writing software was a question of hiring people who are “smart,” a fixed mindset approach. Now we not only know that “smart” is a vague attribute, but we know that the highest-performing teams are learning teams, teams that have a collective growth mindset. // Optimism

Conway’s Law states that an organization will design systems that mirror its communication style. I suspect that it will also manifest a culture that reflects the feedback model used by its employees.

At FloQast, we highly value a growth mindset culture. This means we’re always looking forward and considering how we can improve, both as an organization and individuals, to ensure our future success.

In this post, I’ll explain how we as engineers can work together to help nurture a growth mindset culture through the use of optimistic feedback during code reviews.

Perception + Mindset Shapes Potential

What does “optimistic feedback” mean?

First, let’s consider that there are two styles we use to explain events to ourselves, pessimism and optimism, and each follows specific pattern. A pessimistic view perceives negative events as personal, general, and permanent; and positive events as impersonal, specific, and temporary. To an optimist the opposite is true. They see negative events as impersonal and fleeting, and positive events as personal and permanent¹.

Additionally, there are two mindsets we may employ regarding our capacity for development: fixed or growth-focused. A fixed mindset views talent, intelligence, and capabilities as static and unchangeable, whereas a growth mindset views abilities as constantly evolving through effort and development².

It’s not a stretch to see how the combination of these two factors shape our potential.

Optimistic feedback then is simply feedback given using an optimistic pattern which helps to encourage a growth mindset.

Software is Built by Humans

What does this have to do with code reviews?

Well, as of this writing, computers aren’t particularly emotional. They will execute any code we provide without concern. They are unaffected by alteration and will only complain if the code doesn’t compile.

But that same lack of emotion cannot be said of humans. We are profoundly impacted by what happens to us. And, in particular, we are shaped by the feedback given to us by others.

Without a specific model for good feedback we’ll lean on our personal explanatory styles, both in how we give and how we interpret feedback. At best the outcomes will be inconsistent, but at worst could actually be detrimental.

By using a model to consistently shape our feedback during code reviews, we can build a self-correcting environment of collaboration.

Enabling Better Feedback

Before we look at the details of an optimistic feedback model, let’s first consider some ways in which we can improve the code review process itself in order to enable the best opportunities for great feedback.

Value Each Other’s Time

First and foremost, value each other’s time.

Both authors and reviewers have numerous responsibilities that require their attention. Every context switch requires a focus reboot which is mentally taxing, and it is difficult to write great code or provide great feedback when mental reserves are running low.

So, to authors: before submitting your code, review it yourself. Go through the diff and note anything that may be confusing. Keep in mind that the reviewer will not have the same context as you. If you notice anything that could be refactored in order make it more readable, do it. Otherwise add annotations to anything you think may incite a question.

You’ll get the highest quality feedback if your reviewer can focus on the interesting parts of your code. If you require them to untangle it first in order to make sense of it, you’ll both suffer.

And, to reviewers: be explicit about what you’re requesting. Is it optional, or does it require action? And, if your review is taking too long, or you have too many comments and/or questions, consider switching to a call. A 10-minute conversation can reduce a significant amount of back and forth and possible misinterpretations. Just remember to note the conclusion in the review itself for future reference!

Automate Away Tedium

Recall how computers are passively indifferent about what you instruct them to do? We can take advantage of that. Use to them automate away as much tedium as possible. They don’t mind; but humans do.

Linting, formatting, ensuring tests are passing, code coverage; anything that determines code style and/or quality which can be automated, do it.

Automation allows for switching from policing mistakes to discussing strategy, which allows for more meaningful contributions as a reviewer.

At FloQast, some teams have created shareable ESLint configs which also incorporate Prettier for a linting + formatting combo. To actually automate the process we use husky + lint-staged to ensure all code is clean and tested before it even hits the review pipeline!

A Model for Optimistic Feedback

Now, let’s look at a simple model we can use to help us provide impactful feedback to our peers during code reviews.

Optimistic Praise Should Be Personal, General, and Permanent

Too often, we get stuck focusing only on what’s wrong with code, but reviews also provide a valuable opportunity for offering sincere praise.

Praise can be helpful in reinforcing positive behaviors as well as providing a sense of ownership and accomplishment. It is, however, more than simply offering a nice word. In order to be effective we must follow the optimistic model which says praise should personal, general, and permanent.

If people are to own praise, it has to be personal. And in order to become instilled it must be permanent. Generalize the effect by emphasizing an ongoing arc of applying choices to produce personal growth.

“I love this approach. This will be useful throughout our codebase. Your solutions are always so elegant.”

“I see you put a lot of research into this! I appreciate your explanation and how you always consider all angles.”

“Refactoring this function was a great idea. The code is much more readable now. Your understanding of SRP is really helpful!”

Optimistic Criticism Should Be Impersonal, Specific, and Temporary

It’s easy to shy away from giving criticism for fear of misinterpretation and/or hurt feelings. This is understandable, but by no means does criticism need to be negative; and certainly should not ever be hurtful. It should be used to encourage high performance and the key is to use a consistent model. Optimistic criticism should be impersonal, specific, and temporary.

If you want to inspire change, criticize the code, not the person. Ensure that the feedback is specific. And to encourage growth, the specific criticism must be temporary. Emphasize that this is a temporary blip in an otherwise positive ongoing arc.

“Coverage is looking good, but these particular tests are tightly coupled with the code. If we ever change the implementation they’ll have to change too. Could you rewrite them to test the behavior instead? I think they’ll provide us more confidence that way. Here’s an example…”

“This function does a lot and I’m finding it difficult to reason about. I think it would be helpful for future devs if we could break it into two or three. What do you think?”

“Nice call on this API design! This particular query though will not scale well as our user base increases. Check out the output of the query planner… could you refactor the query to increase its selectivity? This post about query performance on the FQ eng blog may be helpful too.”

A Moment of Reflection

At FloQast, the code review process is highly valued. Each team may follow a slightly different pattern, but overall communication and collaboration are paramount.

If you haven’t considered the impact of your code review process, I encourage you to do so. Perhaps something to discuss during your next 1-on-1.

With the right feedback model, and a touch of empathy, we can use code reviews to not only build robust software but to provide opportunities for collaboration, innovation, and collective growth.

Additional Resources

Check out Reginald Braithwaite’s thought provoking presentation on optimistic feedback and how it affects a collective mindset. It inspired much of the underlying theme of this post.

For a further look into how to communicate with your peers during code reviews in a way that fosters positive relationships, read Michael Lynch’s in-depth guide on How to Do Code Reviews Like a Human.

Vaidehi Joshi asked the greater dev community what they think about code reviews. The answers and insights are fascinating and worth a read.

And, finally, take a look at Google’s Code Review Developer Guide for a detailed view into an effective code review process for both authors and reviewers.

1. See Learned Optimism: How to Change Your Mind and Your Life for more details on these explanatory patterns ↩
2. See Mindset: The New Psychology of Success for more details on these mental models ↩

J.C. Yamokoski

J.C. is a Staff Software Engineer at FloQast who loves breaking down large complex problems into small manageable pieces and attempting to re-explain them in a simpler way. When not hacking at code, he enjoys spending time with his family.