In any non-trivial project there comes a time when code becomes... complicated.

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.

Makes no sense to me. Never did. The speed which the code can be understood says much more about the writer than the reader. I have business analysts, project managers, and users that can read and understand my code. Do you really think that's a valid test of "programming ability"?

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.

Even if that is true, it can still be true that a good way to judge between two coders is to look at how fast they can understand a piece of test code (they look at the same one, of course). If true, it could be a faster test than having them both write an application, no?

Interesting point. You'd have a control, but a control that I place little value on.

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 the point is that you hold the writer of the code invariant, and then substitute different code readers; the rates at which two different people can understand a given piece of code says something about their ability as programmers. More than just rate of understanding, I think depth of understanding is just as important: a novice might read some code and say "it does X", whereas an expert will understand X, observe that the code really meant to do Y, and that it might have memory leaks, deadlocks, or incorrect corner cases, for example.

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.

Good points. However...

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".

Perhaps Gates overstates the case slightly, but I would say that there is a strong correlation between "X is a good programmer" and "X is an effective code reviewer" -- and the ability to quickly and accurately read code and to understand deep, non-trivial properties of the code has a lot to do with being a good code reviewer.

I disagree, for the most part. I think that in most large development shops, more time is spent reading code than writing code (think of the number of minutes each day spent actually typing versus those spent looking at the monitor) and that being able to clearly comprehend what has been written is extremely important. .

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.

"building code that satisfies requirements and works perfectly is a noble goal"

At Microsoft, it may be a noble goal.

With my customers, it is a requirement.

Your customers require perfection? You've got tough customers, then. I assume they refuse to pay maintenance/support fees on principle...

I don't think they're tough. They just treat IT like anything else they spend their money on.

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.

Wow. I can't think of anything I've spent my money on recently that has been perfect, software or otherwise.

  I still think that *one* of the finest tests ...

I agree it is one of the most important trait of a good programmer to understand other people's code. One can only be good at programming by writing code and reading other people's (good) code to keep on improving and acquiring knowledge.

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 you work at Microsoft (or somewhere else with teams and long-lived products), you have to read a lot of other people's code, so its true.

If not, maybe not so much.