8-year-old, to friend: You don’t know how to spell!
Friend: Oh yes I do!
First 8-year old: The opposite of “enemy”—spell it!
Friend: That’s easy: f-r-i-e-n-d.
First 8-year old: Nope!
Friend: Huh? OK smarty, how do you spell it?
First 8-year old: i-t.
How often are you in a meeting, or a hallway conversation, where everyone jumps right in arguing about who’s doing it, or how to do it right, or how to measure it? If you catch yourself for a moment, and take a step back, you see that everyone is talking about something different. Even if there’s a conclusion or a decision, it didn’t really follow from the discussion.
Taking just one example, let’s talk about code review.
Part of being respectful when deploying code review, as with any process, is first checking if anyone is doing it already, and learning those examples. I spend some part of my time these days looking for those people. Every so often I find someone who says, “Code review? Sure we’re doing it.”
But then I start asking questions. I admit I have an opinion in mind. Some minimal attributes of code review. But listening means asking my question and then keeping quiet, so I do.
I ask, are the issues recorded? (Yes? Can I see them? No? Why not?)
Do you review all the code? (No? Why not?)
What does the code author do with the issues? (How do you know?)
When you do these code reviews, what is your goal? (Why? And are you meeting the goal?)
How often are these code reviews? (Haven’t done any in a while? When did it stop? Why?)
I consider myself fortunate when I actually get answers. I haven’t had any positive, consistent answers yet.
Does that matter?
Well, without these answers, I know nothing about it.
So, code review—are you doing it?