If you are a software engineer with even a couple of years of experience under your belt, sharing your knowledge and teaching others becomes an integral part of your job. And the more senior you get, the more it becomes your responsibility to mentor and teach more junior folks.
Being a good teacher is an art and a skill in itself, and today I want to share with you a simple way to make your Code Reviews (CRs) a super powerful and effective teaching tool.
I’m sure you’re already using CRs to not only catch bugs and improve the code base, but as a great mechanism to teach your team best practices and improve their coding skills. But it’s not always easy to get your point across and to get the learning to stick, and I often hear from my clients how frustrated they are to have to correct the same mistake over and over again.
So today I am going to share with you a powerful Jedi technique of how to make your teaching more effective, and the process more enjoyable for everyone involved.
Let’s look at the types of comments you may offer when doing a code review:
Bug! Bug! This is a bug, or a potential problem, this needs to be fixed.
Something is not clear, so you ask for a clarification. BTW, I hope you ask for it to be clarified in code, not in the reply to your CR comment. After all, we want the next person reading the code to not have the same question.
Something works ok, but you suggest a better way to do it, as an optional (or maybe not so optional) alternative.
Any other types of comments you can think of that I left out? Anyone? Bueller?
I’m hoping at least some of you guessed it, the all-powerful positive-reinforcement comment, “You did this really well!”
The power of Positive Reinforcement
Now why do I say that a positive-reinforcement comment is all-powerful? Is it some kind of touchy-feely “everybody gets a star” indiscriminate positivity?
Well, there is nothing wrong with being positive, and we’ll touch on that later, but the first power of positive reinforcement is: THAT’S HOW PEOPLE LEARN BEST.
The simple truth is that when learning a complex task, like programming or riding a bike, our minds create templates for how to do something, not how to NOT do something. After all, there are a myriad of ways to not ride a bike well, but only a few ways to stay upright on those 2 wobbly wheels.
And much like riding a bike, a person learns the quickest from their own successes, rather than from watching someone else or listening to explanations. Even if they did it accidentally, even if they’re not sure why this way is better, if the success is reinforced, they will learn that it’s a good way to do it.
To put it in perhaps more familiar terms, your Code Reviews should be Reinforced Learning with heavy emphasis on the Positive Reward.
Let me repeat the first reason for this – because it will be extremely effective and efficient in helping the person learn what you want them to learn.
Building bi-directional trust
The second reason is that by acknowledging what they’ve done well, you’re letting them know that you see their work as a whole, not just the bugs and deficiencies. And what greater joy is there, than to have your work seen, understood, and appreciated! This will not only make your teammate feel good about themselves and their work, but it will also make them infinitely more receptive and open to any suggestions or criticisms you might have.
The third reason is that positive feedback is an excellent way to build trust on the team. Acknowledging your teammate’s good work will help them trust you, because they will feel seen and valued for their hard work. And, it will help build your trust in them, because you will be training yourself to see the good work that they do, which we sometimes forget to do.
Of course, any positive comment you make needs to be absolutely sincere. And depending on your personality structure, that might take a while. Many of us have spent years, decades, exercising our critical engineering minds, and might have a tendency to see the world, people, and their work mostly in terms of errors and omissions; and have a hard time noticing and acknowledging the positives.
Fear not – like everything in life, this skill can be practiced and trained. And that brings us to homework! Because simply reading this article, even if it resonates and you agree, will do nothing unless you put these things into practice.
Practice Homework
So here’s what I invite you to do:
First, establish the baseline. Write down somewhere private a Coding Awesomeness score for every teammate for whom you do code reviews. On a scale of 1-10, 10 being Coding God, 1 being your cat, write down what you subjectively think of their skills. Save this note somewhere you can find it again (email drafts work well)
Start incorporating Positive Reinforcement (PR) into your CRs. Have explicit numeric goals for yourself for how many PR comments you make in each CR. If you do 0 right now, start with having at least 1 for the first week, and gradually build up. The goal is to get to at least 50% PRs in your average CR, 70% would be great.
Practice this for at least 2-3 months, depending on how often you have to review code. After 2-3 months, score your teammates' coding skills again. Compare to your original score
If you feel like it, I would absolutely love it if you shared the results with me! Comment on this post, send me an email or a message, whatever works. I would be thrilled to hear how it worked for you, and what you discovered in the process
Tips on getting started incorporating Positive Reinforcement in your CRs
You don’t need to wait for them to do something perfectly, or even particularly well before you apply Positive Reinforcement. They just need to do something better than they did before. When you Positively Reinforce the better, you’re telling them they are moving in the right direction.
If you’re having a hard time finding ANYTHING that you like about the code, try to see if there is anything positive you can say about other aspects of the work – did they take on a complex project? Did they do it fast? Did they do some research? Is the work a stretch for them? Did they have to do it under a lot of pressure? Whatever you can say sincerely, say it: “I really appreciate you coding this so fast, so we can review it and iterate if necessary” (if there is a lot of fixing required).
Let me repeat it again – your comments need to be sincere. Under no circumstances are you to fake anything. Whatever compliment you write, you need to believe it. So maybe you need to pause, and to meditate for a few minutes, asking yourself “What did this person do well? What do I like about what they did?” Something will come to you.
If they did something well in one place, but not in another, when you suggest an improvement, it’s good to refer to their own good work for an example “You can simplify this interface so it’s as clean and simple as in this other module you wrote”. It’s very powerful to use their own work as the “good” example of how to do something.
When you suggest an alternative way to do something, first call out what’s good about the way they are doing it, as in “I can see that the way you have is a good way to support potential other use cases that might come up down the road. Another option would be to implement a lighter, simpler API now because it will be easy enough to extend it later, because …”
If somebody already mastered a coding skill, and do something consistently well, you don’t need to keep repeating your Positive Reinforcement of this skill they already embody. You can mention it every few CRs, just to express your continued admiration “I gotta say, I love how you always have excellent integration test coverage…”
Ok folks, that’s it! Let me know if you have any questions, otherwise I invite you to try this out for a couple of months and let me know what happens!
Comentários