Code review habit: Building systems to support goals

“But I don’t know how to make time to do code reviews, I am super busy executing on my own project”. Does that resonate with you? Read on to learn how I put systems in place to break the cycle and make code reviewing a daily habit early on as an engineer.

“Maybe I needed a SMART goal?”

I’ve struggled with that frame of mind a lot and wondered how some of my peers cracked the “code” and were able to review every piece of code produced by the team. I assumed it was a goal-setting problem, so I set a specific and measurable goal to - review all code requests that came my way, every day, and keep track of how many I completed over time (following the SMART goal setting framework), only to realize in a month that the initial rush from the goal-setting exercise died down quickly and I was back to square one.

Building systems to develop habits

After some experimentation, I settled on a system that worked. In order to make code review a priority, I made my schedule reflect that priority and then blindly followed my calendar. My system involved creating 3 dedicated code review time slots - the first 30 mins of the workday, the first 30 mins after lunch, last 30 mins of the workday. Each time slot was intentionally placed to ensure there were ample opportunities to target review requests that came in at different times during the day. When pulled into a meeting at the time, I would intentionally move this code review meeting with myself to another time slot but commit to not canceling it as far as possible.

Consistently reviewing code during those times, helped me stay on top of them, and at the same time it was very predictable for my peers to know when they can expect my review - and it was never more than half a day away. This helped build teammates’ trust, after all, ‘consistency over time is trust’.

Invisible costs of context switching

This system deliberately avoided context switching. While I wanted to achieve the goal of increasing the volume of code reviewed, I didn’t want to sacrifice the velocity of my own execution - which would have definitely been impacted if I were constantly context-switching for on-demand code reviews. Of course, I did make exceptions from time to time depending on the urgency but ensured I didn’t deviate from the system too much.

While this code review system required some initial adjustment, it didn’t drastically change my working style, and the results were very positive. As I transitioned into management, code review time slots switched into generic review slots for design, proposals, and product requirements. Of course, I fall off the wagon from time to time, but the reminder to “prioritize my systems over goals” pulls me back on track. What are some of your systems?

Shoutout to Bef Ayenew for being generous with his time and providing valuable feedback on this article.