How I Learned to Code Part III

So, first I talked my first programming experience, learning via type-in programs. Then I looked at the shotgun approach my university took. In this final post of the series, I’m going to talk about what was the most important learning experience on my path to becoming a developer.

Arriving at college, through type-in programs and from my own study I knew BASIC and 6502 assembly language (the 6502 was the CPU in the Apple II and my friends and I typed in a lot of video games). By the time I left, I’d been taught Pascal, FORTRAN, Lisp, Ada, and three other assembly language. However, the first language I ever got paid to use was C and I learned that on my own.

Sophomore year, I got a job in the Computer Science Terminal Room. Yes, “terminal room”. Dialup wasn’t a wide spread thing yet. Heck, neither were personal computers, the only computer on my 80+ person dorm floor was my Apple //c. You can get a lot of free beer if you have the only word processor. To do your programming homework, you had to trudge down to a terminal room, stand in line until a terminal, an IBM 3270 or a Dec VT220, was free and then do you work.

Working in the term room gave me access to my first UNIX system, a Dec VAX 750 running BSD 4.2. This set the trajectory of my career, both as a developer and a sysamin.

BSD shipped with /usr/games which contained assorted games. One was Rogue, a text based dungeon crawling game. It was a full-screen game, you were an @ and monsters were uppercase letters. It used the HJKL movement keys familiar to any vi user.

Rogue launched a whole class of text based dungeon crawls called “roguelikes”, the first of which was Hack. Hack introduced lowercase monsters and more complicated game play, but what was key to me was the fact that it was open source. Rogue was encumbered by AT&T’s SYSV licensing and shipped as a binary. Hack shipped as source code you downloaded and compiled (yes, we were doing that in 1985).

Hack was written in plain old K&R C. I printed out the source on a big wad of tractor feed paper and read it over Christmas Break. I had a copy of the K&R book and as I read the code, I worked through the book to understand what I was seeing. I learned specifics of the language, for example Hack made extensive use of structs to represent objects and monsters. But, more importantly, I learned about architecture of a big project. How to dived up work into functions, how to organize common functions in to files.

I returned from break knowing C even though I hadn’t written a line of it yet. I couldn’t without access to a server. I’m sure I had plenty of misconceptions, but I also had plenty of ideas of things I wanted to try. I “modded” the game, adding monsters, powerful weapons, and new food (pizza!). The details (and the code) are lost to time, but the experience of reading code, pondering it, and then making changes has always stuck with me.

This is still my favorite way to learn. When I learned Rails I scoured Github for Rails projects, downloaded them, broke them, fixed them, made them better. Likewise for Arudino programming, Chef and countless other things I want to learn. Even when I’m trying out a new gem, I’ll often find a project that uses it and see what they do. I know a lot of tinkerers who work the same way, take it a part, break it, put it together better than before.

Next time you need to learn something, give it a try. It may not work for you. People learn in different ways. The key is to pay attention to what does work for you. How do you enjoy learning? What makes you happy? Do that and you’ll always learn and grow.