"I still think that one of the finest tests of programming ability is to hand the programmer about 30 pages of code and see how quickly he can read through and understand it."
Do you agree this was true in 1986? Is it still true now? If your two answers disagree, whence the difference?
No matter how well designed the code and no matter how often the code is refactored, reality imposes on that neatly designed little world and makes the code sub-optimal.
This is when being able to understand code becomes important. To get inside the head of the author is an invaluable skill (even if the reader and the author are the same person separated in time). To understand why they did what they did (the answer is not always "they were morons"). To understand how to change the code and still guarantee the underlying assumptions.
Also, I would say that being able to read and understand code is even more important when your co-workers are equal to or above your skill level. To try to puzzle out why they did something can lead to an "aha!" type moment which are invaluable in learning new ways of solving problems.
So I would say that being able to read code is important. Maybe not "one of the finest tests" but an important test nonetheless.
I still think that *one* of the finest tests ...
If a person is good (and quick) at understanding someone else's code, it is a good indication of him/her being blessed with a good analytical mind, and experience/habit of delving in to code.
Of course, this ability helps when working in a team, but more importantly it is required to understand the existing solutions and their drawbacks/advantages. e.g. If one intends to write a web server or a new VM for a language, it would be helpful to refer and understand the existing open solutions, before starting out.
In short, the ability to understand someone else's code quickly is a definite pointer of a good potential programming ability. Getting a person to write code is the best test most times, but the ability to adapt and learn new language/technology faster is governed highly by ability to read code.
If not, maybe not so much.
Also, consider:
1. 30 pages of well written code != 30 pages of poorly written code
2. 30 pages of well documented code != 30 pages of poorly documented code
3. 30 pages of high level code != 30 pages of low level code
4. 30 pages of COBOL != 30 pages of BASIC != 30 pages or Java != 30 pages of Python
5, 30 pages of Microsoft code = 1 page of mortal code
The finest test of programming ability is what you can build that satisfies requirements and works perfectly. I'm not sure Bill Gates ever understood that.
In your example, I'd still have them both code something. That's almost always a half hour well spent.
The speed which the code can be understood says much more about the writer than the reader.
I think Gates has a very valid point: there are lots of circumstances where you need the ability to wade into an unknown code base and understand how it behaves (and how it ought to behave). The ability to read through code and understand non-trivial properties of the code really takes some experience to develop -- that is directly relevant to code review, for example.
There's a huge difference between a "needing the ability to wade into an unknown code base and understand how it behaves" and "one of the finest tests of programming ability".
It is clear that well written, well documented code is easier to read than poorly written, poorly documented code. But, for the purposes of Bill's argument, we can assume the code in question is of average quality.
We know enough of Bill's 1986 context to assume that the code he is referring to would be C++ or Assembler. (Included in the book are some pages of the 8080 code for BASIC, written by Bill.) Naturally, the number of pages would vary for different languages, but the argument can be adjusted accordingly.
Finally: building code that satisfies requirements and works perfectly is a noble goal. The question is: is there any test than can be given quickly that acts as decent predictor for this ability? I think Bill's test is not too bad in this regard.
At Microsoft, it may be a noble goal.
With my customers, it is a requirement.
To them, maintenance/support is for changes they want, not for fixing bugs that should have never been there in the first place. Less than 5% is for that.