The title character of Anne Tyler's novel The Accidental Tourist is Macon Leary, a man who hates to travel, yet makes his living writing travel guides for others who also hate to travel. Although the analogy isn't perfect, there are some interesting parallels between Macon Leary and his readers on the one hand, and a group of people sometimes called "accidental programmers" on the other.
I am one of those people. I have been an accidental programmer since 1994, when the Perl programming language entered my life. As such, I have a number of confessions to make.
I took no computer science or programming courses in college. I was a liberal arts major (political science, an oxymoron). Although I enjoyed math during high school, I found the rigors of college-level mathematics daunting, and after satisfying my major's breadth requirement with a year of calculus I gratefully shunned math thereafter. Likewise, I stayed away from the real sciences, taking a smattering of courses based on personal interests (astronomy and archaeology, mostly), but steering clear of anything too demanding.
After college I worked as a teacher, then a trade-magazine editor, and would probably still be doing that today except for an obsessive interest in using computer bulletin boards, which led to the Internet, which led to the Web. In my early days of building Web sites I kept hearing about a programming language called Perl. Without any real appreciation of what I was getting myself into, I picked up a copy of the llama book (Learning Perl), and started reading.
Even though I'd heard that it was better for beginners than the other Perl book one could find in those days (the camel book, Programming Perl), I worked my way through the llama's first chapter in a state of mounting panic. The presentation was moving so fast, and this was just the beginning. How was I going to survive the rest of the book?
What I had overlooked was the part where the author, Randal Schwartz, explained that this chapter was an overview of the material presented later on. Whew. When I figured that out I felt much better. Even so, it was tough going. As Randal acknowledged, the book was written for someone who already knew how to program. For an accidental programmer like me, that was a problem. I had to pick up not only the material being presented, but lots of other material that I was assumed to already know.
My first substantial Perl script, a Web log analysis program I named "webtrax", used 150 lines of index, rindex, and substr invocations to parse its log files. Today, of course, I would just use a one-line regex. That script had poorly chosen variable names, comments that simply restated the accompanying code, and 500 lines without a single subroutine. And, amazingly, it worked. Heaven help the poor person who had to maintain or extend it, but at least in the context of the circumstances for which I created it, it did what I wanted.
I was like a 4-year-old with his first mud pie. I was so proud of that program that I wanted to share it, which leads directly to my next confession.
Of all my confessions, this is the one that pains me most. It is one thing to use crude, poorly engineered code for one's own purposes, but inflicting such stuff on others is a much graver sin. Something about the relative ease of using Perl for Web tasks is intoxicating for us accidental programmers. Overflowing with enthusiasm at the magical results we have achieved, and ignorant of how far short of real programming our fumbling first efforts are, we can't stop ourselves from trying to bring the light of our newfound knowledge to those who still labor in darkness.
I wasn't as successful at this as some (thankfully), but I certainly did my share of damage. Besides the webtrax program mentioned above, I released another really awful program, this one called babymail. (As you can see, I also had a thing for too-cute program names.) More about babymail in a moment.
All of us accidental programmers, with our 10,000-monkeys-typing-randomly approach to software engineering, inevitably give rise to some pretty wacky implementations, and once we've hit on something that appears to work, our compulsion for sharing ensures that the wackiness will spread to the far corners of the globe. Since we frequently don't understand exactly how the software flotsam we've inherited actually does what it does, we tend to keep our cargo-cult code intact, right down to the comments. Like medieval monks dutifully transcribing manuscripts, we confine our embellishments to the margins, fearing to alter the Holy Writ itself.
Anyway, I've done my share of that, too. There probably are still scripts of mine on the Web that feature the hand-rolled form decoding I copied from the CGI documentation at hoohoo.ncsa.uiuc.edu in 1994. As long as no one tries to use them to process a form submission containing multi-valued fields, everything will be fine. If anyone does want to process multi-valued fields (like checkbox groups or SELECT MULTIPLE lists with more than one item selected), though, things will get ugly, since that code overwrites all but the last such value encountered. I'm not the only one in that boat, either; grepping for the telltale comment '# Un-Webify plus signs and %-encoding' in the shared Web space at one smallish ISP recently, I turned up 121 matches, a tribute to the lingering power of faith in these secular times.
Besides being slow to embrace CGI.pm, I undertook, with the aforementioned babymail program, to parse mailbox files by hand, rather than using any of the many superior solutions available from CPAN. That I had no clue what I was doing will be obvious to anyone who actually looks at the program; fortunately, the chances of finding a copy of it are decreasing steadily, as I work to track it down and terminate it wherever it rears its ugly head.
I had been writing Perl programs for years, literally, before I started routinely taking advantage of warnings and use strict. At this point I'm as committed to them as anyone, and can't write a 5-line throwaway script without putting them in, but it took me a while to get there. In trying to recall why I resisted such helpful features of the language for so long, I can only think I was frightened by the profusion of warnings generated from some of my favorite cargo cult code under -w, as I was by the strict documentation's glib discussion of mysterious things like static and lexical variables. It's not that those roadblocks were especially difficult to overcome; it's just that, in the context of all the other things I was having to learn, I couldn't afford (or at least, I didn't think I could afford) any time for the finer points.
I was lucky, in that by the time I came to Perl I already had many years' experience with online discussion groups, and so was able to avoid (mostly) raising old-timers' hackles when I first toddled into comp.lang.perl.misc with my babytalk questions. Many others, of course, aren't so fortunate, and over the years I've found myself occasionally weighing in on their behalf when the predictable fireworks erupt over some newcomer's failure to adhere to [insert relevant Usenet social norm here].
I realize that newbies have had a negative effect on Perl's Usenet culture, and sympathize with those who have watched a cherished online resource become steadily degraded. But I identify with those newbies, and don't think it's fair to punish them, at least not in cases where their only crime is ignorance (that, and the fact that they remind the person doing the punishing of the 10,000 newbies who preceded them).
I attended the first Perl conference in 1997, excited about the prospect of actually seeing my heroes, the authors of the O'Reilly books I'd begun obsessively collecting, in person. I arrived early for all the sessions, sat way down front, and hung around on the fringes of the crowd that surrounded the speakers at the breaks. I was mostly silent, listening in on others' discussion, too intimidated to open my mouth, though when the crowd thinned I sometimes mustered the courage to awkwardly express my thanks. I waited in line to get Larry's (and Tom's, and Randal's) autographs at the book-signing, gaping like an awestruck teenager, and when the conference was over I returned home, my head swimming with the faces I'd seen and the snippets of conversation I'd overheard.
I repeated that experience at the next Perl conference, and the one after that, and the one after that, as it grew and eventually turned into the Open Source Convention. I lost some of my shyness during that time, coming to see the members of the Perl community more as human beings and less as mythic figures, but I still was groupie enough to burst into my hotel room on the eve of the 2000 Open Source Convention, telling my wife and kids I'd just seen Larry Wall sitting in the lobby downstairs. "What did you say to him?" my daughter asked, to which I had to reply, "Eh? I didn't actually say anything. I, uh, didn't want to bother him."
Deciding that it was better to light a candle than curse the darkness, in 1998 I created a novice-level tutorial called The Beginners Guide to CGI Scripting with Perl. The response was gratifying; the site seemed to strike a chord with other accidental programmers, who sent me lots of email asking for more. Emboldened by that, I approached my favorite technical book publisher and pitched them on the idea of a book for accidental programmers, one that explained how to use Perl to create and maintain Web sites. To my surprise, they said yes.
As with my earlier decision to learn Perl, I really had no idea what I was getting myself into. Submitting a book proposal was exciting; having it accepted was really exciting. Actually writing the book (while holding down a day job and helping to raise a family) turned out to be a lot more work than I expected. But now, nearly three years of late nights and weekends later, Perl for Web Site Management is finished.
More than once during the time I was writing it I worried that I might be repeating my earlier sin of publishing bad code for others to use, albeit on a larger scale. Was it hubris for someone like me to even consider writing a book about programming?
I hope not. I'm not the person I was back in the days of webtrax and babymail. I've climbed a fair distance up the Perl learning curve (which in my case has been more like a learning cliff), even if I still gaze up in awe at the heights where the real experts reside. But I'm not so far up that cliff that I don't relate to the problems of those standing perplexed down at its foot, which is why I think a book for accidental programmers, by an accidental programmer, was something worth doing.
In writing the book I've done my best to live up to the example of the most helpful members of the Perl community. It's an example that is reminiscent of Perl itself, the language that doesn't seek to punish accidental programmers for their sins, but simply does its best to help them get their jobs done, using all the diligence, patience, and humility it can bring to the task.
If you're an accidental Perl programmer, or are thinking about becoming one, I hope you'll find the book useful. If you're a more-traditional programmer, maybe even one of those who thinks amateurs like me have no business messing around with programming (to say nothing of writing books about programming), I hope you'll forgive me.