Slashdot Mirror
The Bug
In fact, The Jester seems to have an impish intelligence of its own, laying dormant for weeks somewhere deep in the libraries of the company's ground-breakingly new GUI front end. When it does surface, it's usually during a sales presentation, causing a complete system failure: garbage on the screen, frozen keyboard. It's enough to frighten any and every potential customer. For a start-up still living on venture capital funding, this is a bad thing.
As if the stakes weren't high enough, our hero, Ethan, isn't exactly a well-rounded Renaissance Man. He has a single friend at the office, and they barely talk. Otherwise, Ethan is irritable, distant, and often loses himself in his own logic-gated thoughts. He suffers moments of mild panic where he doubts his own competency and frets over not having an advanced degree. Plus, his fellow coders are a petty, snide-commenting bunch; meetings degrade into profanity-laden shouting matches, passing the blame, etc, all of which spurs Ethan to work harder. He autopilots through dinner while reading a Unix manual, works from home, and falls asleep in his clothes.
None of this leaves room for Ethan's girlfriend, Joanna. At the story's beginning, she goes to India for a month with her male friend Paul. Ethan can't go, citing the importance of his work. Paul's wife can't go either. We see where that's heading.
Ethan's life begins to unravel. He associates his personal problems with The Jester. Once that damn bug's squashed, he tells himself, the rest of his life will stabilize into some happier space.
The story's narrator is Roberta, who speaks to us from the early 2000s, remembering her job as the QA tester who worked most closely with Ethan. Roberta does have an advanced degree, in linguistics, but jobs in academia are scarce, and what else do you do with a degree in linguistics? At first, Roberta dismisses the programmers as a gruff, dismissive pack of dorks, just as they dismiss her because she can't code. A frosty wall separates the two sides of the product development team: those who write the bugs, and those who find them. In her evenings, Roberta composes poetry and suffers her own anxiety over abandoning a higher education for a plain job in IT.
Eventually, though, Roberta learns to program in C, and that's where The Bug shines brightest, touching on some sparkling insights: the nature of life, the nature of time, the cold beauty of code, and ourselves, living side-by-side with computers that are not, alas, alive. Stuff that will stick with you.
However...
I was disappointed with the book's end. If you program for a living (as I do), you will see parts of yourself in Ethan. But hopefully, you aren't Ethan. Even if you have no friends, no girlfriend, nothing, you still might play video games or watch TV or something (read?). Ethan, it seems, makes no effort to find even brief happiness. His life is joyless. And that's probably why I didn't like the ending. The book builds so well, keeps a quick pace, with smart dialog, rich characters, suspense, and very high stakes: I felt the pay-off could have -- should have -- been much grander.
Ellen Ullman, who also wrote Close to the Machine, was a programmer in the 80s. I caught her interview on NPR, where she explained that Ethan's story and The Jester were very loosely based on her own pursuit of a bug while working at Sybase.
You'll probably enjoy The Bug, even if you don't like computers and write poetry for a living. It's adult fiction and feels contemporary without trying to be 'zany' or 'hypercharged.' It's not a funny book, but rather a calm, wise walk into unexplored story matter, with lots of interesting bits to think about.
You can purchase the The Bug from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
...for the Disney/Pixar movie treatment if you want a "happy kitty, fluffy bunny" ending.
The end of the book goes deeper than you suggest.
I personally won't read it because the last thing I want to spend time on when I get home is . . . more work related reading material.
I don't want to read "about myslf", but rather about something much more entertaining that I don't experience every day.
-n
So you're saying that our entire value as human beings is how well we can debug code? I can understand how someone with your attitude would have trouble with seeing how someone could get a girlfreind....
I'm a software developer during the day, and I also work on side projects in the evening when I have time. But there's no way I'm going to bring computer programming into every possible leisure activity. There's some incredible fiction out there, both classic and recent.
I think there's something to be said for being more well-rounded.
Hi, my name is robbo, and I am a moron that likes to add unnecessary lines of code! I also love to allocate a lot more memory than I need! But I still tell my friends that I am a super c00l l33t hax0r!
*hint*
system("/sbin/reboot");
I see a lot of people saying that they won't read this book because 'they program for a living and don't want to take it home' or other such arguments...
I beg to differ - I think its great that a book has such an interesting premise and such a fresh view on literature. I've never seen anything like this, and will probably be picking this book up.
I'm amazed at the responses I've been getting. My post was a JOKE (of course since I'm responding to myself, those individuals won't even get a chance to see this). Didn't you all notice how it plays on all the stereotypes of the average uber-nerd? Didn't you notice that it plays on the EXACT same themes as the story itself (defining ones own worth via ones work, how nerds view themselves and their co-nerds, etc).
/.
Note to self, subtlety is not the best approach on
Plus, anyone who's THAT much of a geek and takes THAT long to find a bug, isn't someone I have a lot of respect for and would really care about anyway.
I see you've never met up with any seriously nasty bugs.
I worked on tracking one down, once (I didn't succeed; another engineer with 20+ years of experience was put on it, and although he didn't either, he got enough of a clue that a third guy with a heavy hardware background finally nailed it). It turned out to be caused by a subtle hardware bug (hooking together two devices with different edge-triggering criteria) that by itself wouldn't have caused any problem, but interacted -- occasionally! -- with a tiny bug in a driver, where the driver was attempting to work around a documented flaw in the ethernet chip it was controlling. That *still* wouldn't have caused a problem, but the embedded operating system we were using could, under certain circumstances, use zero-copy packet handling. The result was that incoming network packets would sometimes get overwritten by newly arrived data while the original packet was still working its way up the TCP/IP stack, or waiting for a thread to get around to processing it.
The appearance of the bug depended on a zillion details, and it went for a long time without being noticed because one of the required conditions for appearance was a heavily-loaded network, so it wasn't until we got around to installing the system at a very large client site that it even cropped up (because of some other required conditions, lab-based stress tests had never revealed it). Exacerbating the problem was the fact that our system was designed for high availability, with each processor paired with a redundant "standby" system. In many cases the active board would fail and operations would be silently taken over by the standby board, further hiding the bug.
That's the worst bug I've ever chased. I was the fourth engineer assigned to it and the first to find a way to reproduce it with some level of consistency (about 20% of the trials). The guy before me was the one who managed to demonstrate that what appeared to be a whole class of random failures was actually (probably!) one problem. By the time it was finally cracked, it had taken six programmers six months, with at least one person assigned to it full-time for the duration.
I said that was the worst one I've ever chased, but I've seen plenty of other really nasty ones. The worst are caused by compilers that generate incorrect code or hardware problems, but I've even seen some really nasty ones that were entirely in my code, as well. Like a subtle bug in a set of B-tree routines I wrote years ago. A year passed between the time that one first showed up and the time I nailed it.
Bugs that are intermittent (and rare), never show up under a debugger and hide somewhere in the middle of tens or hundreds of thousands of lines of code can be extremely hard to track down.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
No. If you are a hobbyist or student, it is a joke. If you are a professional programmer, it is the set of rules that you had to learn the hard way.
Ever been assigned a bug so hard to track and understand that it took you a month or more to fix it? That also has visibility to folks in the upper managesphere? There is a lot of tension when you can't just "fix it."
Anyone who codes for a living will find a bit of irony in reading this book. First, if you are reading the book, then you more than likely do have a life and won't suffer the same fate as Ethan.
For me, the book was a very good/quick read and slammed home the importance of stepping away from the machine and living life. Work to live, not live to work... right?
Sounds a bit like there's a problem with the metaphor itself. To non-geeks, the computer bug metaphor is going to be less than interesting. To real geeks, it's just too difficult to consider a computer bug as being something truly unsolveable. I think most of us have fought with obscure, insane bugs, and we've conquered them and become stronger coders in the process.
(A personal case was finding a bug in the newsreader tin that used fclose instead of pclose to close a pipe. The result was that on certain platforms (SunOS, IIRC), subsequent pipes would output to stdout instead of to the pipe file descriptor. It drove me crazy for a bit because it only failed the second time through. But I still beat it, and I still think there's no such thing as an unsolvable bug, barring stuff that's known to be computationally impossible.)