Sounds too good to be true, huh?
One of my programmers is cool enough to request a code review with me when something critical is at stake. I can’t really read code and he knows it. So why does he keep suggesting we do code reviews?
He realizes said activity will force him to explain his code at a translated-to-layman-terms-level. Occasionally, I’ll ask questions; “Why do you need that statement?”, “What if the code flow takes an unexpected path?”. But often I start to daydream…not about my weekend or other non-work things but about a previous statement the programmer made. My brain gets hung up trying to grok the code. And while I’m lost in thought, the programmer keeps zooming through their code, until…
…all of a sudden, the magic happens.
The programmer says, “Hold on…I see a mistake”. It happens every time! I kid you not! A different programmer on my team found two errors while explaining his unit tests to me Monday.
Now I’m not suggesting testers should daydream their way through code reviews. And of course, a tester capable of actually reading/understanding code is more valuable here. But I am suggesting this:
If you’re a tester who feels too uncomfortable or inadequate to perform a code review with your programmers, remember, all you have to do is listen and occasionally ask dumb questions. And even if you’re bored to death looking at someone’s code, and you fall into a daydream, who knows? You may have indirectly helped your programmer save the world.
RSS
I am flattered to finally get mentioned in your blog! I think more value can be added to this process by the tester not day-dreaming. That sounds obvious, of course. But, what I mean is that as the dev is explaining his or her code line by line, the tester might be able to visualize the sequence of what the code is doing and create a sequence diagram or something in their head or on paper. That will help the tester check that the implementation of the logic accords with their understanding of how the logic should be implemented. Honestly, that is mainly what I intend to happen when we do this--along with the "magic" that you point out.
PS: I am not your programmer. You are *my* tester. Beeotch!
Yes, I agree, Anonymous programmer. I'll try to do more visualization of the scenarios.
Perhaps if you make the code review more interesting, I would not drift off. For example, you could give the methods their own voice (maybe that British accent you do) and the objects could have a different voice (falsetto or something). You could make it like a little story.
That would be something.
That would be something. I'll try that next time. :)
'grok the code', well put :)
I think I will suggest the British accent idea to the developers I work with.
Sounds similar to the "Rubber Ducking"-exercise I´ve written about here: http://agile-and-testing.chriss-baumann.de/2010/10/rubber-ducking/