Deduped images

10-01.html

@@ -46,7 +46,7 @@
 <P>It goes without saying that pattern matching is good; more than that, it&#146;s a large part of what we are, and, generally, the faster we are at it, the better. Not always, though. Sometimes insufficient information really is insufficient, and, in our haste to get the heady rush of coming up with a solution, incorrect or less-than-optimal conclusions are reached, as anyone who has ever done the <I>Times</I> Sunday crossword will attest. Still, my grandfather does that puzzle every Sunday <I>in ink</I>. What&#146;s his secret? Patience and discipline. He never fills a word in until he&#146;s confirmed it in his head via intersecting words, no matter how strong the urge may be to put something down where he can see it and feel like he&#146;s getting somewhere.</P>
 <P>There&#146;s a surprisingly close parallel to programming here. Programming is certainly a sort of pattern matching in the sense I&#146;ve described above, and, as with crossword puzzles, following your programming instincts too quickly can be a liability. For many programmers, myself included, there&#146;s a strong urge to find a workable approach to a particular problem and start coding it <I>right now</I>, what some people call &#147;hacking&#148; a program. Going with the first thing your programming pattern matcher comes up with can be a lot of fun; there&#146;s instant gratification and a feeling of unbounded creativity. Personally, I&#146;ve always hungered to get results from my work as soon as possible; I gravitated toward graphics for its instant and very visible gratification. Over time, however, I&#146;ve learned patience.</P>
 <TABLE WIDTH="100%"><TR>
-<TD WIDTH="5%" VALIGN="TOP"><IMG SRC="images/10-01i.jpg"><TD WIDTH="95%"><SMALL><I>I&#146;ve come to spend an increasingly large portion of my time choosing algorithms, designing, and simply giving my mind quiet time in which to work on problems and come up with non-obvious approaches before coding; and I&#146;ve found that the extra time up front more than pays for itself in both decreased coding time and superior programs.</I></SMALL>
+<TD WIDTH="5%" VALIGN="TOP"><IMG SRC="images/i.jpg"><TD WIDTH="95%"><SMALL><I>I&#146;ve come to spend an increasingly large portion of my time choosing algorithms, designing, and simply giving my mind quiet time in which to work on problems and come up with non-obvious approaches before coding; and I&#146;ve found that the extra time up front more than pays for itself in both decreased coding time and superior programs.</I></SMALL>
 </TABLE>
 <P>In this chapter, I&#146;m going to walk you through a simple but illustrative case history that nicely points up the wisdom of delaying gratification when faced with programming problems, so that your mind has time to chew on the problems from other angles. The alternative solutions you find by doing this may seem obvious, once you&#146;ve come up with them. They may not even differ greatly from your initial solutions. Often, however, they will be much better&#151;and you&#146;ll never even have the chance to decide whether they&#146;re better or not if you take the first thing that comes into your head and run with it.
 </P>