(10 minutes read)
About a year ago, we were trying to teach my 2-year old son to go up the stairs one foot at a time. It was interesting to watch him learn. He quickly got the first half right: He would get his right foot up and push on his right leg with enough strength to lift himself up. But strangely he would never use his other leg. We weren’t quite sure why. Most likely because once he had learned a way to go up one step, there was no need to learn another way! I remember being behind him and telling him constantly: “OK now the other leg… No not that one, the other…” He would still use his right leg. “No, no no! The O-THER LEG!!” No matter what I said, it would always be the right leg. This lasted for a few weeks and what was amusing at first became a little frustrating as he only made use of that right leg. We had tried to lift his left leg to show him how to do it. We had his older brother show him the example. I mean… We just tried so many things in vain… Until something happened.
As we were headed towards the staircase together, he put forth his usual right leg and pulled himself easily up on the first step. But then, instead of targetting my thoughts and words on his left leg, I congratulated him on that easy right step: “Allright!!! Good job Clement!! Way to go! That’s great!!” He paused for a brief moment and listened while I cheered him up. And then, out of nowhere, he lifted his left leg, put it down on the step ahead and lifted himself up! I cheered him up even louder as he quickly went back to his right leg, and hop he went back to his left leg! In a breeze, he was now going back and forth with his little 2-year-old legs.I felt one of those rare privilege moments that a parent feels for his child. It was an amazing discovery for me: my child was much more driven by positivism than by explanation, example, or any other means of education.
A few weeks later, I wanted to try that same experiment at work. In my day to day job, I write code, I read other people’s recent/old code, I perform code reviews, I conduct technical interviews, I share common code with my team, etc. In the end, a lot of what I see as a coder is the output of others. As a software developer, I found that it is extremely easy to look at someone else’s code and focus on the WTF parts. In front of our monitors, our digital world of code is often depersonalized and rarely displays signs of tolerance for errors. I personally found myself being mostly negative when it came to dealing with what others were producing.
At that time, I was struggling with one member of our team who was working remotely on the other side of the world. It seemed to me that no matter what I tried explaining, i ended up being disappointed with what he produced. Most likely the language barrier made it hard for us to exchange clearly on the expectations for quality. His work was uneven: sometimes it was really good and often it was just plain awful. Anyways, he had just completed a feature and was waiting for my code review. I spent a good hour looking through his code. Every time I would see an error, I would mention it. But most importantly, I was now on the lookout for the good parts. I was able to find 3 methods that he had actually written really well. They were clear, concise, well thought out and unit tested. I proceeded to write long comments praising those methods, I mentioned it again in the code review summary, and again in an email. Maybe the impact was amplified by him being used to seeing me grumpy all the time, but boy did I not expect the outcome! A day later, he had made some awesome changes to his code. He had rewritten every other method so that their quality would equal or surpass the 3 methods I had highlighted. All of his code became great code! This was an eye opener for me.
I decided to keep going. With time I quicky found out that while no code is perfect, it always leaves just enough room for positive feedback. In every code review, pull request or answer from interview candidates, there were always positive things to spot and emphasize.
I had to be careful not to encourage bad behavior. This required me to make sure i wasn’t just tossing positive comments out of the blue. Bad code does not magically become good code if left unchanged. The experiment was not about dismissing the bad parts, and I never stopped underlining the bad or erroneous code that I saw. But as I gazed through lines of code, it was all about taking that additional time, sometimes twice the time, to look for and highlight the positive things that I saw: an algorithm which was well written, portions of code which were very clean, smart ways to handle a problem, etc. The aim was to cheer up my peers whenever they produced something good, with the hope that it would carry them one step further. I always made sure to largely outweigh the negative by the positive. If there were 2-3 things to be fixed, I would try to find 4-6 positive things.
The results were quite surprising. What I had discovered with my son was also true with everyone else, me included. Interview candidates became much less stressed out whenever I provided positive feedback on the correct answers they would give, thus increasing the rate of successful interviews. Code reviews which used to require multiple back and forth exchanges now brought much better fruit as the corrections were often perfect right off the bat. The relationship between team members improved and noone was left to code in the dark. The overall quality of our code increased and generated much less issues. I really can’t take any credit for any of it, as the behaviour quickly spread: everyone started doing likewise and most team members were doing it much better than I was.
I am sure that this can be applied pretty much everywhere. The majority of comments on the internet is negative feedback. This is simply explained by the fact that those who agree and enjoy a product or article rarely take the time to mention it, whereas those who disagree feel a natural need to voice out their opinions.
We may all be different as coders, but noone is immune to legitimate and thoughtful positive feedback. To praise a part of someone’s code is to show appreciation for one’s intellect. It increases self-esteem and confidence, it boosts morale and generates a desire to become a better coder. Were you looking for new objectives for the coming year? Take the additional time to look for the positive in what other people produce, and you will not only create greater code overall, but you will also be part of a much greater team.
Thanks for reading, and Merry Christmas!