This was no sudden revelation. When I was hiring, I had a standard question to see if candidates could read code. Here is the code snippet.
Candidates had to try to figure out what function f was doing.
int function f(somestruct *a) {
int x = 0;
if (NULL == a) {
return 0;
}
x += f(a->left);
x += 1;
x += f(a->right);
return x;
}
First, I expected the candidate to see the left and right fields and guess that "a" was a pointer to a binary tree of some sort. I then expected the candidate to see the pattern of the recursive calls and guess that it was a tree traversal (inorder in this case). Once that's done, its simple to try out the function with some data and figure out what it does (count the number of nodes).
Given that everyone learns about binary trees, and especially inorder traversal, you would have expected many to get it right. Surprise! Only a few have ever got it correct.
Most answers were something related to linked lists or arrays. It seemed that every programmer when confronted with a pointer in any form assumed it was related to linked lists!!
To be successful at code reading, it is the ability to execute the program in our mind that needs to be developed. This is a learned skill, developed by just reading lots of code.
One conclusion is that many programmers don't spend enough time reading code. It also explains why in many teams, most code becomes spaghetti — programmers can't read the original code, so they hack their fixes.
So, do you check to see if programmers can read code? As an aside, you can now find out how most programmers can't write code either.