For my job this summer, I'm programming computers. (This news should surprise approximately nobody.) I don't know how I got started with computers to begin with, but I remember the moment when I knew I'd be a good programmer.

The math behind the Mandelbrot set involves complex numbers, but is actually simple to do. A complex number is a number of the form a + bi, where a and b are real numbers and i is the square root of -1. In other words, a complex number is a number that has both a “real” and an “imaginary” part. So it's sort of 2-D. Just like with x and y, you can plot complex numbers on a piece of paper by drawing two axes: one along the real number line, one along the imaginary number line. Just like with x and y, you can take an equation involving complex numbers and draw a graph of it.

Mandelbrot's math starts out from this familiar terrain. The equation to be graphed is z² + c, where z and c are complex numbers. As with any function, you put a number in and get a number out. But for Mandelbrot's purposes, you don't plot that first result: you plug it back into the function, get a new result, and repeat again and again. If the result gets infinitely large, then the starting point isn't in the Mandelbrot set; otherwise, it's probably in. To get a good graph, you have to run every point of interest through this cycle. It turns out there are infinitely many points of interest. A computer sure would help.

We had a Mac Plus (born-on date: 1986). For computations it was very slow. It partly made up for this by having a very small screen. (Seriously, this significantly reduced the number of points to calculate.) My first program to graph the Mandelbrot set, following the algorithm described in all the books, took nine hours to run. Ouch.

I couldn't imagine that real researchers sat around waiting nine hours for each new graph. Quite possibly they were using better computers. I was stuck with mine. If I wanted faster turnaround time, I had to figure out a faster way to draw the graph.

I set to thinking, where is the slowness? The standard algorithm loops over every horizontal and vertical pixel on the screen. For each pixel, it does these repeated calculations. It takes less time to compute the pixels that aren't in the set (because you can stop when they're obviously going to infinity) than the pixels that are in the set. Wait a minute, the Mandelbrot set has a continuous border, and everything on the inside is in the set, and everything on the outside is out. So if I can trace along the border, I can skip calculating all the interior and exterior points. That'd speed things up. Great idea; can it be done? If I have some pixel that's on the border, I can check each of its eight neighbors and walk my way around. All I need is a well-defined starting point. Is there one? Sure, the point (1/4, 0) is precisely on the edge. Start there.

Holy crap, is that all there is to it? My algorithm was so simple that it couldn't possibly work. But why not? I frantically rewrote the code and ran it. The first point was plotted immediately. Then another. And another. And another. I watched agape as it made its way around that familiar outline. My new program drew the Mandelbrot set in a watchable twelve minutes.

A 45x speedup was more than I'd hoped for; exactly what I'd wanted; and accompanied by the realization that by doing my own thinking, I'd outsmarted the literature. No two ways about it, I belonged in this field with these guys. Of course, learning how and when to reuse other people's code came much later.