Secrets of Code Review
Secrets of Code Review#
The Case for Peer Review#
A policy of peer review can stop bugs before they reach the customer.
Although the team needs to know the language, have an open culture, not take the code personally
It’s not your code - it’s the company code. The company pays you to write quality company code and make the best decisions given the constraints.
Collaboration is rare in the development stage - unlike the requirements and infrastructure phase.
- No one is catching obvious bugs
- No one is making sure documentation matches the code
Think of a book by any author - the first edition always has spelling and grammar errors even after review. Why would developers write files without mistakes.
Example: You are an engineering manager of Adobe Reader on Windows and you are responsible for adding 5 new features in 9 months. Adobe reader is valued at $1 billion.
the question: Which of those five features is so compelling, it would be worth introducing a crash-bug in Reader just to have that feature?
Answer: None!
Only code review will ensure that new hires don’t make mistakes that veterans would avoid
Code review:
- Reduces the number of delivered bugs
- Keeps code maintainable
- Gets new hires productive quickly and safely
Summariser note: New hires - whether junior, mid or senior - are still new hires. They must spend most of their time reading, learning, listening and watching in the first few months.
Delivering bugs to QA costs money; delivering bugs to customers costs a lot of money and loss of goodwill.
A successfully-implemented code review process is a competitive advantage. No one wants to give away the secret of how to release fewer defects efficiently.
Summariser note: Even when people know the benefits their ego is high and confidence low. They are more focused about not being wrong and showing that they are knowledgeable than producing better quality.
Resistance to Code Review#
Authors have editors, accountants have auditors, and scientists have peer review journals.
Main reasons codes don’t like the review:
- Programmer egos
- The hassle of packaging source code for review and scheduling review meetings
2 Camps#
When someone is looking over your work - it can either be constructive or critical.
- Collaborators - people who do what it takes to work out a solution - including asking other people, saying they don’t know. Code review is seen as a beneficial process.
- Isolationists - people who will continue to thrash away at a problem they can’t solve - rather than reveal to their peers that they need help.
The later have shorter careers is software development - their body of knowledge is constrained with what they think they know. No what they know they don’t know or what they don’t know they don’t know. Even for smart people - they will be limited.
Attitude can be as important as aptitude.
A programmer needs the ability to work in teams, to listen carefully, to take risks, and to learn from their mistakes, in order to survive in the typically fast-paced environments in high-tech fields. A continuous interest in learning consistently enhances and sharpens skills, and allows programmers to continue to be productive (and marketable!) in a constantly changing field.
Programming is an art and a discipline. A programmer tends to have to create solutions, as opposed to engineering fields where most problems are categorized and the known solutions applied. A programmer creates/invents a solution that is both sufficient and necessary. A programmer works in bursts of an altered and height- ened state of consciousness to produce. If you ask someone who works in this mode to provide a weekly status report, or attend a corporate pep rally, or sit through the weekly department meeting, you’ll typically be met with a groan of disdain, or an excuse about having that Sev-3 deferred feature they’ve been meaning to get to.
There are now tools that make code review easy.
Summarisers note: Most of the essay waxes lyrical about code review strengths and why people don’t like them - then the last sentence mentions tools that easy the struggle - but does not elaborate