Okay, I'll risk my career and admit it: I not only know how to draw a flowchart, I still find myself using them from time to time.

I have one of those little green plastic flowcharting templates to help draw the symbols and arrowheads, but I don't use it much anymore. (I don't like to take it out of its climate-controlled vault; the chill might warp my precious slipstick.)

I'll bet a few of you are smiling wistfully right now, secretly yearning for The Days of Boxes and Green Plastic: the expansive surfaces of glistening unblemished flowcharting paper, each patterned page awaiting its chance to represent pure logical art. What mere "problem" could possibly withstand our iterative onslaught of ink and thought? Get thee behind me, General Ledger!

Yes, they were simpler days, or perhaps it was just me who was simpler. Ah, but those first tastes of process abstraction (imposing order upon thought, what a concept!) were just too alluring.

My first exposure to flowcharts wasn't until college. I know for a fact that I was much simpler then, but fortunately so were the programming problems I faced. There always seemed to be a way to get that virtual boxcar attached to the virtual train without having to lift it off the virtual tracks. No list went unlinked, no record went unwritten, and no parameter went unpassed, by value or by reference. Simpler days, indeed...

When I look back at my proudest individual programming achievements, I can't help but start with that first college-level Pascal programming course. The instructor was meticulous and unwavering: no global variables without solid justification (which meant no global variables), all local variables descriptively named and declared alphabetically, and every procedure well begun with a standard commentary prologue.

That's how they lure you in. "Come on! Here! Impose order on an unruly universe... You can do it!" Yes, that was my first foray into flowcharting, and something in me changed.

I remember rushing to my then-future wife one bright summer day, waving my multipage fanfold printout, and proudly exclaiming, "Look! This Pascal assignment took over a HUNDRED LINES of CODE! Isn't that AMAZING!?" She smiled, and I fell in love (which is the only hard proof in existence that I do, in fact, have moments of brilliance).

Next it was a thousand lines of this and a thousand lines of that ­ logistic equations, with variable zooming, grid lines, and decimal input fields; fractal monster functions, continuous yet nowhere differentiable; images of reality that no one in the history of man could ever have seen in the days before transistors on silicon. I came to know the Turbo Pascal graphics library by heart. Programming these ugly beige boxes to display such unfathomable beauty was reaching deep into the viscera of the silicon beastie and twisting. I liked it. I was hooked on programming.

Then I got a job, and it was my guts' turn to be twisted... "Oh, Mandelbrot sets are fascinating and beautiful and all, but we really need that big honkin' component test plan you promised us. Okay?" The joy of individual, top-to-bottom programming ­ just for the fun of it ­ was still there, but there was also a different, even better, kind of joy: the joy of contributing to something much, much larger.

My first big chance to prove myself part of the team was during the development of a new optimizing compiler back end for our box. The theory of compiler front and back ends was new to me then, though its simple elegance was instantly compelling.

The idea is simple: separate the compilation process into two phases ­ a "front end" and a "back end." The front end converts source code to an "intermediate representation" (IR) ­ a form that completely and unambiguously represents the form and function of the compilation unit, but which does not presuppose any particular hardware configuration. Then, a compiler back end gets involved, and converts the IR into optimized, hardware-specific instruction streams and data structures.

The sweet part is this: any software that can be compiled into a given IR will run on any hardware that has a matching back end. Now, if this sounds familiar, it should. It's arguably the very heart of the write-once run-anywhere promise of Java.

At the front end, we have javac, Jikes, or anything that generates proper bytecode. (There is at least one RPG-to-bytecode compiler, for instance.) The IR, of course, is the classfile format. The back ends are the various JITs, AOTs, and true interpreters that make our JVMs work so well.

Imposing order upon thought... What a concept! Maybe those boxes and arrows and diamantine decisions led somewhere after all.