Now that’s not to say I was exercising my creative genius way back then. (Not in that medium, anyway.) No, my dad had a Commodore 64 and a subscription to Compute! magazine, which came with 5-10 pages of code for a game in the back of every issue.
It made for great typing practice, but the way I did it didn’t really teach me a lot about programming. See…I would just open up a command-line and then sit for hours copying all the PEEKs and POKEs and GOTOs line by line into the machine. I did it in order, and when I got to the end, I would run the program and see what happened.
If I’d done it perfectly, I could play the game. Once. As soon as we turned off the computer or loaded any other program, though, it was gone.
But, of course, I rarely did it perfectly. Usually there was a line missing, a variable misspelled, a PEEK pointing to 6643 that was supposed to point to 6463.
Sometimes that meant funny effects in the game. Sometimes it meant a spectacular crash, ending the game abruptly just as I got to the good part. Most of the time, it just meant nothing happened. The game wouldn’t run. Maybe it gave a detailed error report — I don’t recall — but if it did, I had no clue how to read it.
That’s…well, that’s not really how programming works. It’s not now, but it wasn’t then, either. I just didn’t know what I was doing. I should have been saving all that work, so a game that played could be run again and aagain — and one that didn’t could be fixed.
I didn’t learn any of that until two decades later, when I finally let Toby try to teach me how to program. He’s a master of it. During our years in college I’d watched him work some real wonders with programs he put together for class or for fun, but I wasn’t too sure he could convince me to enjoy it. I remembered way too many failed efforts of my own.
We talked about it for several months. He made me read a book. And then, finally, he told me to just come over and watch him work.
So I went to his place and sat down next to his spot at the computer. He clicked through a bunch of pages of dense code, rambled a bunch of meaningless explanation, then he tried to run it so I could see the magic in action.
Then he said, “Oh. Hmm.” Nothing happened.
Well, I guess something happened. He got an error message. I felt terribly bad for him, but he just opened another document, scrolled through to the right spot, changed a word on the page, then nodded in satisfaction.
He ran the program again. Then, again, “Oh. Hmm.”
We had two or three hours to work on the game, and spent at least two thirds of it on, “Oh. Hmm.”
And I watched, fascinated, as he debugged a program in development. By the time we were done I understood some of the issues, and even some of the fixes, but for the most part I just watched him darting here and there through an unbelievably complex web of functions and variables, adjusting, tweaking, fixing.
And then, at last, he said, “Aha! There we go.” And just like that we were playing.
It’s been seven or eight years since the first time that happened — and it has happened frequently since then, across various projects, consoles, and programming languages. These days, I just expect it.
In fact, these days I do the same thing. I remember trying to show off a program I’d written to Carlos, not too long ago, and it went precisely the same way. “Hey, check this out! Oh. Hmm.”
I remember a time when I thought typing in that initial code was “programming.” It’s not. It’s typing. Programming doesn’t have anything to do with inspiration, with sitting down at a blank page and making something incredible. Programming isn’t really about making but about fixing. It’s everything that happens between the “Oh. Hmm.” and the “Aha! There we go.”
That can be a surprise to novices (it was to me), but to real programmers it’s the most obvious thing in the world.
Speaking of which…do I even need to make the application to writing? Well, I’m going to. Come back Thursday, and we’ll talk some more.
Photo courtesy this guy.