Explaining our triumphs.

[For those readers not interested in programming, bear with me. This post is actually about writing in the end.]

Today at work, I solved a technical challenge that I had concluded was impossible a few years ago. This wasn't an earth-shattering discovery by any stretch, and I'm sure that someone somewhere has thought of this before, but my solution to this problem was a sideways one, and that's always really satisfying. It took all day to code (which is really long for a single feature for me), but now I have a way to:

Automatically script all changes to all stored procedures, table triggers, and functions in 2+ (presently 4) connected databases on a single server. The reason that this is a triumph is that it was all accomplished in completely native T-SQL code in SQL 2000, and can all be administrated from a single database without any hard-coded links to the other databases. Even better, I figured out a graceful way to detect when the same peice of code has been changed in multiple databases that share an identical codebase -- I can even recognize which ones were identically updated and which ones are now in conflict with one another.

Now, if you're one of the fellow writers who frequents my blog, your reaction is probably "uh . . . whatever." That's fair enough, if you're not an experienced SQL programmer. Even if you've worked with databases for years, if you're not familiar with the nuances of dynamic coding techniques, system tables, cache strategies, and cross-database scripting (especially dynamic cross-database scripting), then it's unlikely that you'll have any chance of understanding why I'm so pleased.

It's the same way I'd look blankly at you if you told me about something brilliant you did to fix your car, or some sort of crazy new technique that you used to save a patient's life today. You can explain all you like, even laying out exactly how your entire triumph was accomplished, but I still won't get it -- not really. Oh, if you're good at explaining I could follow what you were telling me, but there's no way that someone not already an expert in your field is going to have a true appreciation. The listener's reaction is likely to either be "that sounds easy" or "that sounds impossible, like all work in your field" depending on the nature of your explanation.

As a programmer, I generally have the benefit of being in a "that sounds impossible" field. Certainly some users occasionally think that a difficult task should be much easier than it actually is, but more often programming is regarded with a certain degree of mysticism. I'm really going to miss that when I'm a full time writer someday. Just because most people can type or construct sentences, they assume that novelcraft is a lark.

I've spent several hours this evening reading my work out loud, editing like crazy, and the result is a much tighter, much more varied-sensory-inputs, much more speakable and eloquent prose. I can say this to all of you, and you understand immediately how this is an accomplishment. But a frustrating number of outsiders are more likely to wonder what the big deal is. After all, when they sit down to pen their first of many bestsellers, their first draft will be so perfect as to merit immediate publication (and bags of cash) sans any editing at all.

Resist the temptation to hit these people. Instead, build relationships with your fellow authors; they understand what you're going through when no one else is likely to. If you have to explain your triumph past a certain level to a lay person, you probably can't explain it to them. Even the best-written words cannot communicate ideas that the reader is not prepared to accept. That last is actually an important thing to remember in general.