Ask YC: Code Digesting
14 comments
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.
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 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.
If not, maybe not so much.
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.
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.
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.
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".
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.
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.
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.
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 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?