Good advice. It also has the tangential benefit of making legacy work easier. If you have to come back to a system months or (heaven forefend) years later, it helps immensely if you were careful to understand EXACTLY what you were doing the first time around.
I used to be guilty of "compile, tweak, repeat" and I found that I wound up with a lot of places where I had done something which "fixed the problem." Really, it'd just made the compile error go away. There was still a problem there, but because I didn't understand it, it popped up to bite me later.
As a legacy programmer, the article title also works in another respect. I work on projects that were originally coded by a cast of about 6 different programmers. The first thing I do when getting a new bug fix or feature request is to ask who the original programmer was. Depending on the answer I know whether I can count on the programmer to answer questions about their code or whether I'm on my own.
This approach is strangely similar to Woz's work habits in designing the Apple II. He intimately made every aspect of that work part of his brain's firmware. After reading about that in Chapter 3 of Jessica Livingston's Founders at Work, I have made a conscious effort to do the same with my software.
I used to be guilty of "compile, tweak, repeat" and I found that I wound up with a lot of places where I had done something which "fixed the problem." Really, it'd just made the compile error go away. There was still a problem there, but because I didn't understand it, it popped up to bite me later.
As a legacy programmer, the article title also works in another respect. I work on projects that were originally coded by a cast of about 6 different programmers. The first thing I do when getting a new bug fix or feature request is to ask who the original programmer was. Depending on the answer I know whether I can count on the programmer to answer questions about their code or whether I'm on my own.