First, a little story . . .
Years ago, before I joined Microsoft, a team at one of the companies I worked for decided to start doing code reviews. This was back before modern IDEs that would show you side by side code comparisons with color highlighting of the proposed changes. And before VSTS which allows you to annotate the code that you’re looking at — add questions, notes, or recommendations about the code you’re reviewing — which is kept as metadata for the code. All good stuff.
So, no, we didn’t have anything fancy, so up front we agreed that we’d print out the source code before the meeting. We’d have to find a spot on our calendars when all ten of us could meet. We’d book a room. Then we’d meet.
The first review was pretty awkward. Nobody wanted to be the first, then Tony relented and agreed to be the Guinea Pig. He printed out his code for everyone, we met in the room, and we all started looking over the code. Things started off OK. There was some nervous laughter, Tony described the section of code we were going to review, and people asked a few questions and made some general comments. It went on like this for several minutes. We didn’t really know what we were doing.
One of the senior people on the team was Steve. He’d had a lot of programming experience, had worked on a number of different systems, and could crank out code. He was also the team lead, and the other newbies and I would sort of look up to him. But, Steve had an especially sharp tongue.
Steve asked a question. “Why in the world did you write your code this way?” Then another. Then made a barbed comment about the code. And another one. During this first code review his questions and comments began to come out as grilling and accusations. He’d say stuff like, “That’s a horrible name for a variable.” And, “I could have written this in half the lines and it would be 10 times faster.”
It went on like this for what seemed like hours. Steve even said, “This is really bad stuff. Why did you become a programmer? How did you get a job here?” I was so glad that I hadn’t volunteered to go first. I looked over at Gregg. He was wincing. Sandy had a look of horror on her face. The others, same. And Tony. Poor, Tony. He was shrinking into his chair.
After about 15 minutes of this, Gregg finally got up the nerve and broke in. “Hey, wow. OK. I think it’s time for a break.” Everyone agreed. We all grabbed our stuff and got out of the conference room as fast as we could.
And we never had another code review.
Culture. . .
Developing software is so much more than language, syntax, patterns, IDEs, and mad technical chops. (Although they do come in handy.) Developing software is more about people. It’s about soft skills, being able to understand and communicate with others. It’s about solving problems.
Developers — even beginning developers — pour their souls into the code they write. They can be passionate about their code. They’re totally invested. It’s their baby, and nobody likes to have their baby called ugly. And nobody wants to be put down or humiliated.
So, some things to think about before the code review. . .
- What’s the purpose? Why?
- If the code has some issues, is that a good thing or a bad thing?
- Is the code review for punishing or for teaching, mentoring? Blaming or training?
- If issues are found, explain why. Reach an understanding. Teach.
-
- What are the consequences of the way the code was written?
- Help them figure it out. Don’t simply mandate or dictate. Teach them how to fish
Code reviews can be so beneficial to everyone if they’re done the right way. And so harmful if they’re not.
Be kind to each other. Play nice.
musings from a snowstorm 