Chris Hansen and Code Reviews
About a year ago I blogged on how I thought Chris Hansen would make a great DBA. A few people said they liked that blog post and I loved the idea of getting Chris Hansen involved but he has yet to return my phone calls, emails, or telepathic messages.
Anyway, as I was assembling materials for the book, it occurred to me that Chris would be best suited to handling code reviews for any IT organization on the planet. So I included it in the book, inside of Chapter Four, “A Development Server is a Production Server to a Developer“, and here is the excerpt:
Chris Hansen and Code Reviews
Good code reviews are a necessary evil. They should be performed at regular intervals, perhaps at a project milestone or tollgate. Code reviews are a time for you to explain to your peers your thought process as well as receive feedback on your code and design. The end result is better code, which results in a more stable system, which results in less production support issues. So why are most companies not bothering to do code reviews?
Because everyone dreads code reviews.
Most people are not good at presenting, and on top of not being good they know they are not good and that makes them even worse. Some people could be good, but get nervous when talking in front of a group of their peers. And those that are having their code reviewed feel as if they are being interrogated by Chris Hansen from “To Catch a Predator”. It all adds up to some of the most dreadful assemblies of employees you could ever hope to imagine.
So, we know code reviews are important, right? And we know that everyone dreads them and as a result no one does them anymore, right? Now, I want you to imagine that Chris Hansen is leading the code review and you are the developer currently making your presentation. You get done explaining what you are doing, and Chris starts asking you some questions, such as…
CH: “Do you know how old DTS is? What were you thinking? And you were not going to batch your transactions? Do you know what that will do to your log file?”
You: “I swear man, it was just talk, that’s all it was. I wasn’t going to do anything. I came here to tell my DBA that we needed to go our separate ways.”
CH: “Just talk? It’s a lot of talk. I’ve got the transcript right here. You say here ‘I want to cursor through all your rows’. Man, that’s just wrong.”
You: “I know, I know. I’m getting help. The other day I bought a book on SQL 2008. And I am willing to do whatever I can to help you guys. Just tell me what you want me to do.”
CH: “Help us?”
You: “Yeah, with whatever.”
CH: “There’s the door. Go tell your friends we’re watching. And the next time they hand us deployment instructions that are more complicated than a NASA launch sequence we’re coming after them.”
Clearly you don’t want to have things go that far, but there are going to be times when you really want to call a developer out and ask them why they have their head up their ass. Stay calm, no one person knows everything, right? But also put yourself in their shoes. If every piece of code that you just spent weeks putting together was being picked apart you would be defensive, right? So it is natural to see the developer get defensive as well. In fact, it is natural for anyone to be somewhat defensive even if their code is not being picked apart.
Do your best to see this as an opportunity to teach something new. Not everyone wants a lesson, however, and for those people you need to remain calm and try your best to persuade them to see things from a different point of view. Find out their roadblock (why don’t they want to do something new) and help them get around it. Over time people will begin to trust your feedback rather than think you are always on the offensive.