Typical tech team conversation:
“The work is nearly done, just a few tidies but it basically works.”
“Has it been properly tested?”
“Not yet, but the basics work.”
“And any changes that come out of a code review, I assume.”
“True, but hopefully not many.”
“So still a fair bit to do then.”
“Yeah, a bit more.”
We’ve been running code reviews for a few years in a fairly tiny team with a mix of experience. For context, we don’t generally have strong specialisms, and do a fair bit of picking-it-up-as-we-go. Over the time, I’ve noticed two fundamentals:
- Nobody likes code reviews
- The right attitude to code reviews goes a long way, both for individuals and for the business
Part One: Nobody likes code reviews
You’ve just spent days using nothing except your brain and fingers to craft a solution (elegant or otherwise) to the latest user need — brilliant! The problem to hand is solved, everyone will love you, blah blah blah. Onwards and upwards.
Except — Code Review.
(If you’re not familiar with the term, then a Code Review is basically a chance to run what you’ve done past someone else. This. Is intended to catch bugs, raise questions about the work, point out improvements (including style, documentation, formatting, etc), and learn from each other. The actual benefit will depend on who’s reviewing who — it can be beneficial for a junior member of staff to review a senior member’s work, and vice versa, but the dynamic will obviously change.)
The word itself is horrible; “review” sounds so judgmental. Like your work is going to be scored out of 10 by some gravy-train critic with an axe to grind. The code works, doesn’t it? Why does it need anything further? This isn’t school any more.
There are two main reasons to be “afraid” of having your code reviewed:
- Explaining things to others is hard and boring.
- Being “wrong” is difficult.
This gets at a fundamental “double-think” that helps in code reviews — and, indeed, in life. On the one hand, how can we be proud of our work so that we can take interest and responsibility for it, while simultaneously being humble enough to accept critique?
Part Two: The right attitude goes a long way
In order to not hate code reviews — and to become stronger as a result of doing them — we must therefore develop a key set of skills as a programmer being reviewed:
- Respect for the person reviewing, whether they’re more senior, junior, or an equal peer — without this, we cannot be open to suggestions from them. (And vice versa, it is essential to respect the person whose work is being reviewed. This mutual respect is the key part of the “contract” underlying reviewing each other’s work.)
- Patience to explain something (often to someone who may otherwise have no idea about context)
- Clear communication — storytelling about what you’ve done (and not done), and (more importantly) why you’ve done or not done it
- An inquisitiveness that opens us up to collaboration, to help explore feedback and suggestions arising from review.
By focusing on these as key skills to develop, a team can learn more quickly from each other. Individuals can improve their own skills faster, as well as learn more about working with other people generally — an essential, yet subtle side-effect of code reviews is learning how other people think. By being open to alternative thought processes, we can expand our own, and bring wider experience to problems in the future.
As Tech Lead (or a senior developer), what can I do to encourage these properties in the team?
The main, most essential thing is to simply lead by example. It’s good to become part of the process by reviewing code (as may be expected, depending on the team size) and adhering to the values above. But also it’s important to write code and be reviewed — this demonstrates what you believe to be good practice. Plus everybody has something to learn off others — often a junior member of staff reviewing your code will ask you basic questions that get you to think about your basic assumptions.
Secondly, and this is something I’d like to bring in more, it’s valuable to be very clear about the aims and values of the code review process up front. Inform new staff about why code review is important, and remind people every now and then.
It’s very powerful to be able to say that a team can learn from itself rather than rely on books and courses, or that a developer’s job entails learning and teaching, above and beyond simply pushing out lines of code and UML diagrams. Learning and teaching is something a good team does all the time, as a matter of course.
I haven’t touched on more detail here, such as what the main attributes look like, or what to look out for to see if a team really are developing as a unit — maybe I’ll follow up with these in a later blog post, if there’s interest.
Originally published at Workweek.
