February 7, 2009
I started programming in 1981 on a TRS-80 Model III. The splash screen of one of the few commercial programs I saw started by drawing a frame around the edge of the screen, starting at the top center and moving left and right at the same time, down the sides, and meeting at the bottom center. It then drew its logo in the middle of the frame. That was the coolest thing I’d ever seen.
Every program I wrote after that had such a frame and logo. I’d spend the first
hour making the frame and logo, then maybe go on to write the actual
program. But there was a catch: You couldn’t use print@ to draw the
characters of the frame because writing to the position in the lower-right
corner would scroll the screen up one line.
So I had to poke the frame. Poking is writing a byte directly to memory, in this case the frame buffer’s memory. About half the time I’d get my math wrong and write one byte off the end of the frame buffer, crashing the machine and wasting 20 minutes of work. (Saving to cassette was too difficult to do often.)
I recently downloaded a TRS-80 emulator. After writing the obligatory program that asks for your name and prints it out, I wrote the program to draw the frame. Not only did it only take me two minutes, but it ran correctly on the first try.
This surprised me. Why was this so difficult when I was 10 but so trivial today? It’s just addition and multiplication and looping. I couldn’t put my finger on what skill I had now that I didn’t have then. Maybe my loops were 1-based then, but I know today that 0-based math is easier to deal with.
In college I spent a year keeping track of all my bugs and compile errors, to see if I could find patterns. I made many changes to my programming style as a result, but the single most significant change wasn’t related to a specific bug. It was just re-reading the code I’d just written. This massively reduced the number of compile and logic errors in my code, since I’d catch problems immediately.
I’m guessing that this was the most significant reason why my program last week worked on the first try. I read it over before running it. This would be the number one advice I’d give to a new programmer: Read your code after you’ve written it.