On the Self-Introduction of Doom

Very rarely anymore do I feel like giving writing critique or notes of technique outside of my reviews for Tor.com. I make an exception in this case, however, because this will otherwise show up repeatedly in my reviews of certain series books, should I ever get to them.

There are quite a few series out there using the first person or nearly exclusive single third-person limited, which is quite fine with me (it can annoy others, but I’m not one of them). Coupled with a desire to keep a series enterable at any point, however, and all too often the combination results in what I call The Self-Introduction of Doom.

In the Self-Introduction of Doom, the main viewpoint character starts reeling through a blaze of who they are, what they are, the quirks their unique career and lives have taken, their motivations, their sometimes supernatural neighbors, every important turning point and event in the last X books, and sometimes repeating a briefer version of same for their closest compadre(s). This can go on for pages.

It’s rather like an interview with the reader where the character presents his or her or its resume/C.V., and the reader is left to evaluate this.

Let me tell you honestly: it’s boring. We, the readers, are being informed of the character’s personality and past; it’s telling, not showing.

Here’s a comparison from real life.

There are times when I, a programmer deep in the bowels of a company whose interview routines are typically at the difficulty level of Seattle’s Big Three, must interview candidates. Despite the enormous potential for interesting conversations, I am horribly bored stiff through most of them.

This is because, no matter how many buzz words or team experiences or leadership experiences or even job experiences my interviewee tells me about, they all mean nothing if the candidate cannot demonstrate their experience. It’s not just simple coding questions about recreating word count programs: I will ask architecture, design, OO, debugging, systems integration, testing questions. I develop and elaborate based on how the candidate is doing. I am not a hardass, either; some of my colleagues are even tougher.

But someone who can walk away from the standard script, who can think outside the box, who can flexibly engage with the problems—indeed, who can take the criticism I levy at then when I challenge their answers and methodology—those people we hire.

Similarly for readers trying to drop into the middle of a series.

Do not be the candidate who keeps referring to his experience and never, ever shows me an iota of their ability away from their curriculum vitae.

Show me what this character can do, as if this were the first time I was meeting them (because it often is). Don’t even start the Self-Introduction of Doom because I will not care until your character has completed showing me some damn mettle.

This is difficult and demanding. I know. I am difficult and demanding. But I’m the one who needs to end up buying the book in order to even consider a review at all—I do get some subsidies, but publishers will rarely give out eArcs. And in a way I’m glad, because then I also have a customer point of view on my reading.

For those curious: I will almost never cut an interview short ((Exceptions include those who assume I’m HR and not an engineer due to my gender, those who try to hit on me, those who get visibly angry when I don’t take their resumes for granted, those who lie to me—trust me, I know who’s participated in the development and bug fix patches for JUnit—and all of these have happens to me or a colleague.)) , and I will read the full chapter the Kindle store offers as a sampler, but despite my general leniency in this area, my rejection rate is still high.

So it goes.

Sorry for being evil. There are too many programmers, too many books, not that much money, and definitely not enough time.

Update: Corrected spelling. Someday may iPhone get a spellchecker….