Coaching and review
Atul Gawande wrote about how he used a personal coach to take his performance to the next level. In his case, he reduced the errors he made while performing surgery. The key was to get what he calls a “personal coach”, someone who could objectively look at and judge his performance, and provide concrete, actionable feedback.
What struck me was how specific and nit-picky the feedback was. For example:
We sat in the surgeons’ lounge afterward. He saw only small things, he said, but, if I were trying to keep a problem from happening even once in my next hundred operations, it’s the small things I had to worry about. He noticed that I’d positioned and draped the patient perfectly for me, standing on his left side, but not for anyone else. The draping hemmed in the surgical assistant across the table on the patient’s right side, restricting his left arm, and hampering his ability to pull the wound upward. At one point in the operation, we found ourselves struggling to see up high enough in the neck on that side. The draping also pushed the medical student off to the surgical assistant’s right, where he couldn’t help at all. I should have made more room to the left, which would have allowed the student to hold the retractor and freed the surgical assistant’s left hand.
Code reviews also tend to be nit-picky. Style issues, formatting, naming. But what seems to be nit-picky ends up being important. When dealing with very large repositories of code, these seemingly insignificant flaws are like pebbles on the tarmac. If you let them build up, pretty soon your smooth tarmac becomes a gravel road.
My own “aha” moment for realizing the true value of code review came to me when I noticed that I myself was writing the kinds of messy code that I would call out when reviwing other people’s code. But I was blind to it because I wanted to quickly get to the point where my damn code would work already. We all are.