Last week, I discussed a fascinating new study about cognitive bias in software development from the University of Oregon. Researchers engaged in essentially a pair programming exercise, but instead of participating in the coding themselves, they simply watched the devs as they went about their work. They documented various cognitive biases, and how those biases showed up in the programmer’s decisions.
Fortunately, the researchers didn’t just point out common problems but also developed helpful practices that can be used to avoid these mistakes. I was delighted to discover that many practices in their list are already being used at Rewind today, both from within my team and the company as a whole. From this list, I thought I’d share three helpful practices for mitigating cognitive biases in programming, which I’ve learned at Rewind and have seen the greatest impact.
Prioritise time for documentation
We all know we should do it, but it often gets overlooked and becomes challenging to keep up with as the desire to continue building takes over. Documentation time can be spent in two ways: reading or writing.
There was no lack of internal documentation at Rewind for me to read when I first joined. I quickly understood what was happening at the company and how to set myself up to start my new job. Instructions on how to set up my development environment were clearly written and supportive documents were available for common issues with solutions. It made for a very positive onboarding experience because there was no need to guess or assume how things should be done. During my onboarding process, I also read software documentation to get up to speed with the tools and languages used within the company. This is something that my team and I still regularly do today to ensure proper usage of tools and languages. I’ve learned to get into the practice of checking documentation anytime I encounter something I don’t fully understand. Even if it is not technically needed to solve the problem at hand, it contributes to my understanding of the system as a whole, which impacts my solution to said problem since everything is connected.
I have personally felt an equal benefit in writing documentation as reading it. From doing this, I have often discovered that really challenging problems can be solved if broken down and approached piece by piece. Rather than jumping right into coding, I am able to step back to fully consider the problem and explore all potential solutions before making a final decision about the best path. Expressing a problem in words engages the brain in different ways that helps uncover more answers than if the problem were to remain a mental thought. It also makes it possible to show others, allowing for collaboration and knowledge sharing. This also benefits everyone in the future, as it provides written evidence for how and why decisions were made. Overall, limiting the room for personal assumptions as much as possible as the system is being built.
Collaborate on decisions, brainstorming, and problem-solving
One of the best ways to challenge our biases is to expose ourselves to different perspectives. Doing so allows us to compare and contrast other options for how things can be done. It can also reveal our own errors in thinking, providing the opportunity to correct ourselves before mistakes are made. This, of course, requires a positive environment where others can feel safe to share and have meaningful discussions. I personally can feel quite nervous about sharing my own thoughts and ideas sometimes, in fear of appearing incompetent if I say something wrong. But I’ve found that Rewind has a very healthy dynamic for collaboration, as everyone is in shared agreement that it is okay to be wrong. In fact, it’s natural. No one is right 100% of the time, so it is completely unrealistic to expect anyone to be. I have learned that sharing my ideas, including incorrect ones, ultimately helps everyone get to the right idea more quickly.
Pair programming is another form of collaboration that I do a lot within my team. It can feel nerve-wracking to code while others watch, but as with other challenging tasks, the more I did it the more comfortable I felt. Of course, my team’s positive dynamic also contributed to this. Assumptions I’d unknowingly make would quickly get checked as others would point out things I didn’t see myself. Explaining what I was doing while working helped me gain a lot of awareness about my coding behaviors and habits. Especially when I was asked why I was doing what I was doing. I began to constantly ask myself that question as I worked. When I didn’t have a good answer, my unconscious biases would reveal themselves, and I’d catch myself before making a mistake based on my assumptions or habits.
Be consistent with reviews and feedback
Building a successful product requires iteration because nothing is done perfectly in the first go. Whether it’s a piece of code or a document, having extra eyes always helps because reviews help refine and bring work to a higher level. All of that is fine and well, but putting your own work up for review and being open to feedback can be easier than it sounds. It challenges one’s ego and can require you to stand up for your ideas or embrace someone else’s. What has helped me is remembering that everyone shares the same end goal of producing good results. With that in mind, it becomes less personal and the focus shifts to the work itself rather than the person who built it. This can however strongly depend on how feedback is given. Starting out at Rewind, I made many mistakes in my first pull requests. My ego took a hit each time a mistake was pointed out by a team member and I was really hard on myself for not doing things correctly. Unexpectedly though, my team would also give positive feedback in the same pull requests that had mistakes. That positive feedback was really encouraging, and it made the negative feedback easier to receive.
In the same vein as collaborative work, reviews and feedback allow for other perspectives and encourage self-reflection. It also ensures that all available information is accounted for in the solution design. Missing a possible scenario or condition isn’t a matter of lacking intelligence but rather lacking experience. Other developers who have written similar solutions in the past could have encountered bugs or unexpected issues. So mistakes can be avoided if others can pass on their knowledge from prior experiences.
Understand bias in order to code better
In conclusion, there are many ways that our brains can trick us into thinking that something is the right way when it is not. If left unchecked, it can wreak havoc on our work without us knowing it. Thus it is important to build good practices to stop these natural behaviors from taking over. I highly recommend reading the research article that inspired this post, particularly the helpful practices table. We are fortunate to have access to information that can help us better understand how our brains work. So it is really up to us to use that to become the best version of ourselves.
Interested in growing your skills with us? See our open positions below or join our talent network to be the first to know about new opportunities with Rewind.
Nhu Tran">
