See Braidy Tester Read Code. Read, Braidy Tester, Read!

I've been reading through code for one of the tools we are investigating using.  This particular tool has been used by lots of other people for years, so any bugs that would prevent us from using it have likely been found by now.  I'm not reading this code for the express purpose of finding bugs, anyhow.  A lot of our testing will use this tool, so we want to know that taking this dependency will make our testing better, not worse.

A lot has been written lately about reading code.  Diomidis Spinellis wrote "Reading, Writing, and Code" plus an entire book on the subject, Eric Lippert wrote "Reading Code Is Hard" in two parts (Part 1 and Part 2, "the" Wiki has Tips For Reading Code, and the always funny Matt Warren gave us a glimpse of "Programming In [His] Brain", just to name a few.  I don't know if this is just an interesting coincidence along the same lines as every movie studio putting out similarly-themed movies every year ("Coming soon to a theater near you:  Alistair Cooke reads leaked Windows 2000 source code!"), but reading code seems to be front and center these days.

Reading a foreign language is often easier than writing it, but the opposite is true for code.  Writing code involves converting the model of the system or algorithm in your head into a bunch of text the compiler understands.  Reading code, on the other hand, involves rebuilding that model of the system with that compiler-ready text as your only guide.  This is hard enough to start with, but if the author attempted "clever" tricks, named members badly, let comments rot (or left them out entirely), or committed any of the other crimes I continually rail against, understanding the code can be nearly impossible.

But what doesn't kill you makes you stronger, as the saying goes.  Developing the ability to read and understand unfamiliar code (including, as everyone always loves to say, your own code six months from now) is vital to your success in becoming an expert developer or tester.  More important even, I dare say, than developing your coding skills.

As for reading unfamiliar test cases, well, everything I just said goes double.  Good test cases are even harder to write than good code, and (yes) much harder to find, so the ability to read and understand them is highly prized.  The upside, though, is that the paucity of good test cases and good code provides plenty of opportunity to practice!

*** Comments, questions, feedback?   Want a fun job on a great team?  Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com.  I need a tester and my team needs a data binding developer, program managers, and a product manager.  Great coding skills required for all positions.