TITLE: Woz Sez: Take Some Time To Get To Know Your Program Better
AUTHOR: Eugene Wallingford
DATE: May 16, 2020 11:33 AM
DESC: 
-----
BODY:
Steve Wozniak in
<A HREF="http://www.foundersatwork.com/steve-wozniak.html">
   Founders at Work</A>:

<BLOCKQUOTE><EM>
 If you can just quickly whip something out and it's done, maybe
 it's time, once in a while, to think and think and think, "Can
 I make it better than it is, a little superior?"  What that
 does is not necessarily make the product better in the end, but
 it brings you closer to the product, and your own head understands
 it better. Your neurons have gone through the code you wrote,
 or the circuits you designed, have gone through it more times,
 and it's just a little more solidly in your head and once in a
 while you'll wake up and say, "Oh my God, I just realized a bug
 that's in there, something I hadn't thought of."
</EM></BLOCKQUOTE>

<BLOCKQUOTE><EM>
 Or, if you have to modify something, or add something new, you
 can do it very quickly when it's all in your head. You don't
 have to pull out the listing and find out where and maybe make
 a mistake.  You don't make as many mistakes.
</EM></BLOCKQUOTE>

 Many programmers know this feeling, of having a program in your
 head and moving in sync with it.  When programs are small, it's
 easy for me to hold a program in my head.  As it grows larger and
 spreads out over many functions, classes, and files, I have to
 live with it over an extended period of time.  Taking one of Woz's
 dives into the just to work on it is a powerful way to refresh the
 feeling.

 Beginning programmers have to learn this feeling, I think, and we
 should help them.  In the beginning, my students know what it's
 like to have a program in their head all at once.  The programs
 are small, and the new programmer has to pay attention to every
 detail.  As programs grow, it becomes harder for them.  They work
 locally to make little bits of code work, and suddenly they have
 a program that does fit naturally in their head.  But they don't
 have the luxury of time to do what Woz suggests, because they are
 on to the next reading assignment, the next homework, the next
 class across campus.

 One of the many reasons I like project courses such as my compiler
 course is that students live with the same code for an entire
 semester.  Sure, they finish the scanner and move on to the parser,
 and then onto a type checker and a code generator, but they use
 their initial stages every day and live with the decisions they
 made.  It's not uncommon for a student to tell me 1/2 or 3/4 of
 the way through the course, "I was looking at our scanner (or
 parser) the other day, and now I understand why we were having
 that problem I told you about.  I'm going to fix it over
 Thanksgiving break."

 In my programming languages course, we close with a three week
 three assignment project building an interpreter.  I love when a
 student submitting on Part 3 says, "Hey, I just noticed that some
 parts of Part 2 could be better.  I hope you don't mind that I
 improved that, too."  Um, no.  No, I don't mind at all.  They get
 it.

 It's easy to shortchange our students with too many small projects.
 I like most of my courses to have at least some code grow over the
 course of the semester.  Students may not have the luxury of a lot
 of free time, but at least they work in proximity to their old
 code for a while.  Serendipity may strike if we create the right
 conditions for it.

 I have already begun to think about how I can foster this in
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2020-05.html#e2020-05-14T14_35_15.htm">
   my new course</A>
 this fall.  I hope to design it into the course upfront.
-----