As technology gets newer and I get older, learning new things becomes frustrating. For example, I want to learn how to work with MySQL for web development, program 3D games, and play the guitar, but my lack of ability in these areas prevents me from achieving my overall life goals. There’s also day-to-day stuff that, as a 40-year old American male, I feel I should know: balance my household finances, invest in the markets, ride horses, and flirt with women without throwing up. These are tasks that are, from my perspective, hard to learn for several reasons: a lack of good mentors, reference materials, and classes. And that’s even without mentioning the magnetic properties of my ass with respect to my couch.
When I overcome these obstacles, I still hit the proverbial brick wall; for whatever reason, my brain can’t quite deal with the important task of learning before getting bored or sleepy, and I end up going to get a sandwich instead or watching Age of Love on TV.
It’s easy to presume, as I join the ranks of the Newly Old, that my mind is becoming less flexible. This is the common wisdom; for example, people say that it’s tough to learn languages when you’re older, and that we should have done it when our minds were most facile: around the age of 6, I think. Although I don’t have any studies to back me up, I’m pretty sure that other factors are greater contributors:
- We’re self-conscious about not being competent in front of other adults, so we iterate less and thus learn more slowly.
- We’re not particularly motivated, given that mass media tells us it’s supposed to be easy. When it’s not, we give up.
Since we’re all grown up and have our own money, we expect to be able to buy knowledge and expertise readily. It’s really amazing just what you can buy, and we’ve grown to expect the easy access or we get real mad. It doesn’t help that our advertising, at least here in the USA, tends to emphasize the quick and easy fix. We expect instant gratification, and thus we’ve forgotten how hard it was to learn our first lessons, and we’ve also perhaps forgotten how to learn for ourselves. I wonder if kids these days even know what it’s like to have to wait for anything.
A LESSON FROM THE PAST
Yesterday morning I was doing my morning coffee thing, glumly looking at all the things I wanted to do that I was unable to follow through with due to a lack of understanding. One of the main ones has been transitioning my blog to Expression Engine, which I think will allow me to more easily expand the content offerings on my website while improving overall service. I had met up with Mark J. Reeves recently for lunch recently to catch up, and asked him about the possibility of writing a web service that would save data from my Flash Apps and integrate with the Expression Engine user management system. Mark, who’s a competent execution-oriented web developer, told me exactly what I needed to do: write some SQL queries to access the pertinent database tables, maybe even repurpose the underlying blog engine to store data for me in custom fields. The problem: I don’t know SQL, or what tools to use, or even how to talk to the database. I am paralyzed by not knowing what the best practices are, haunted by issues of scalability and security, and most importantly of all: I was not looking forward to learning all that stuff. I could not readily apprehend the structure of the material, and therefore I could not approach it logically.
Reflecting on this experience, I found myself reminiscing about my youth, when I first started learning about computers. Today, computers don’t scare me at all, and it’s because I have experienced them nearly to the transistor level of operation. As a result, I can look at a computer system and “read its aura” to figure out what’s really going on. That is now, but when I was in the 7th grade, computers were as mysterious to me as, um, MySQL is to me right now. I vowed that I would master the computer and learn all its secrets. Somehow.
And so I started my notebook:
Some historical notes first: this actually isn’t the original notebook: it’s a manually-transcribed copy. The original copy went to a kid named Derek Bumpas, which I handed to him just before I graduated; he had a good attitude and was eager to learn even though he was in the 8th or 9th grade. He recently contacted me, some 20 years later, to say that getting that notebook had meant a great deal to him, and had helped put him on his path in computer science. That was really nice to hear.
When I first started taking these notes—recall that there was no Internet, hard disks, or multi-window multi-tasking operating systems—paper was the only way to simultaneously take notes and learn. Every nugget of wisdom gleaned from hours of tinkering was transcribed, as cleanly as I could, into this notebook so I could share information with friends at school. There were all kinds of things in the book, all of them interesting to me. It was, in essence, my spellbook. Here’s some of the entries:
An Applesoft BASIC routine to reformat a long string so it would display nicely on a 40-character wide text display; in today’s desktop publishing terms, it does “ragged-right justification” for a monospaced font. This was a common task that I had to solve in my various text-based programs, as I was pretty obsessed back then with things looking right. I finally wrote it down…my first incantation.
As a high school kid without any money, we often “had” to copy software. The difference was that software back then came on 5.25″ floppy disks that were copy-protected using peculiar algorithms; it was a fun challenge to try to figure out exactly how to elegantly disable them by rewriting the program code. This was my real education in computer software debugging. The code listing shown here is written in 6502 assembly language, revealing the method behind the protection. By understanding the principle behind the interaction with the disk hardware’s imperfections and the software code that exploited them, a copy-protected disk could be transmuted into one that was easily-copied with everyday copy utilities.
As I started to understand assembly language, I learned how mapping the interface between code and hardware (the “input/output”, or I/O routines) allowed one to zero-in on the game logic itself. For example, say I wanted to be able to change a shooting game so I had “unlimited bullets”. By looking for the specific code that read the joystick button state (e.g.: is it pressed?) I could easily find the code that was responsible for checking how much ammunition was left. And once you decode one piece of code, you can infer the purpose of surrounding code. I was able to modify the game Beyond Castle Wolfenstein (the original Apple II one from 1984) to give me a 30-round submachine gun with burst capability, and rewrote the opening story to explain why you had one in the first place. This changed the nature of the game quite dramatically. By documenting the logic behind the software and noting the location of critical routines, the granting of unnatural abilities within the game world became possible.
I attended an American high school in Taiwan, and software was difficult to find for teaching purposes. Taiwan being a rather gray area in terms of copyright, my science professors would sometimes enlist my help to help them make backups of the US-sourced software; the humidity and mold in Taiwan tended to eat disks very quickly in the sub-tropical environment. Most of the time, educational software was protected with fairly straight-forward techniques using off-the-shelf protection systems. Because they were rather generic, the same general process could be used to remove the locks with just a few steps. In this photo, I wrote down the process of disenchanting this particularly piece of software, which required the use of a specialized instrument called “Advanced DeMuffin”.
THE PHILOSOPHER’S STONE
And then there were the great unsolved challenges against which I beat my head. Electronic Arts had a very advanced protection routine that was designed specifically to defeat the casual copy breaker; you needed special hardware installed in your computer to even get at the code, and then you needed to understand it. I spend many hours trying to understand just how Electronic Arts’ incredibly fast boot system worked, and once I understood that I tried to trace how they were doing the copy protection. Smarter crackers in the U.S. had already done it, but it was beyond my abilities and knowledge to follow. Here’s a fragment of my research on the area…to me, to be able to understand this code would be like transmuting lead into gold. I should search online to see if any back issues of Computist describe this. I still kind of want to know how it worked.
THE MODERN SPELL BOOK
It’s been years since I’ve kept any kind of notebook like this, with the exception of my patentable ideas journal. There’s so much material out there now that the task of learning is equated with finding resources: the right teacher, book, or online tutorial is perceived as the “magic bullet” that will get things done. However, what I have forgotten is that the process of distilling these ideas into a form that I can invoke at will is necessary as well. It’s my missing link.
I went out and bought some of the larger Quadrille-ruled Moleskine Cahiers ($14.95 for 3), and pasted a paper label on the front of it (the picture is at the top of this post). The idea is to start recording the same kind of notes that I used to do in the 7th through 12th grade; looking back, it was a highly productive period of time for me, though I didn’t recognize it then. I’m thinking of just writing down really basic things that are currently mystifying, by hand, for reference in this book. I know there are plenty of reference books and online sources that purport to do this already, but do you think any aspiring wizard would buy their spellbook off-the-shelf? NO WAY! They would be told by their cantankerous mentors to go find a sturdy book and pen, and transcribe their spells themselves by hand. Because that’s the way you learn, and that’s the way you bind the magic to yourself.
WHAT WAS OLD IS NEW AGAIN
Packaging the information into nuggets as I learn, which I used to do when I was younger, may be the way for me to approach the new technologies that are making my head hurt now. As an adult I had expected things to get easier, but really they are just as hard. Fortunately, I now remember how I worked through the challenge.
We’ll see how it goes. In the meantime, I’m just pleased with the way my new SQL notebook looks :-)