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