This is why I read Chris Lema

chrislemaIf you asked me a year ago who Chris Lema was, I wouldn’t be able to tell you. My experience up to that point was a brief mention by my friend Josh at Event Espresso that his was a blog worth reading. Chris tweets a lot — one of my biggest turn-offs when I am looking at people to follow on Twitter — and his blogged looked like business, marketing and strategy stuff. At the time, I didn’t look any closer than that. Sure, it seemed like he was Kind of A Big Deal, and lots of WordPress-types followed him, but that’s not really my bag, baby, so I moved on.

Then Chris was on the DradCast and later spoke at WordCamp Miami (which was livestreamed), and it was there that he blew my mind in his description of his hiring process and setting up a situation where your applicant is going to fail, and deciding whether to hire them based on how they failed. It was a process that mirrored my experience with the Automattic interview and trial process that I’d gone through not too long ago. (Yes, I interviewed and trialed for Automattic. Suffice to say, if I had gotten the gig, I would have blogged up to high heaven about it. Instead, I think of that as the first attempt of however many it takes. And now that I know the rules of engagement, I can be better prepared for next time.)

So, I started following Chris on Twitter. I still don’t RSS his blog because, honestly, I rarely look at my RSS feeds anyway except to see if there’s a new XKCD. But I have a couple services that suggest stuff for me to read based on who I follow or what other stuff I read, and that’s how I came across his post on the best tools for your website.

The man knows how to tell a story

In college, I was in a storytelling seminar. Partially I enrolled because storytelling, to me — especially at the time — was code for role-playing, and I knew the person leading the seminar — a former student — used to role play. But he was also an amazing storyteller. We had pseudo-tribal bonfire gatherings where we started a bonfire, played drums and danced, and told stories in the traditional Native American sense. We had our own oral tradition, tall tales of the Tree of Many Things and the White Buffalo. (Our war cry/chant was “BUFFALO!” — you really need to hear the story to understand. And even then, it’s pretty random. Just go with it.) And when Ben told the stories, people listened. He was easily the best storyteller in the community.

I say this, because — despite the fact that my Storytelling class had nothing to do with role playing — I know a thing or two about crafting a story, about building the plot and engaging your audience. The class was largely about storytelling in the oral sense, but the same rules apply to writing — at least if you’re writing in a certain style.

Chris is a storyteller. Rather than writing a dry blog post about tools, he opens the post with a story about paintballing. The common theme is being prepared (or unprepared), and the actual tools he talks about, don’t come in until the tail end of the post — a brief top 10 list with no real elaborate description behind any of them.

THAT, my friends, is why I read Chris’ blog. Because it’s the exact opposite of what I thought his blog would be when I first went to his site a year ago. It’s not dry, marketing and business school stuff (I mean, I’m sure there’s some of that stuff in there, too), it’s stories. I went paintballing once, too. I was the same age as the 10-16 year olds he described and it was in a big, converted warehouse, with forts to climb on and hide in and walls to hide behind. It was the paramilitary wet dream of a 10-16 year old who grew up watching G.I. Joe cartoons and it was awesome. Anytime anyone talks about paintballing, it grabs my attention, and the metaphor he uses to tie it into starting a blog works.

Go read Chris’ blog. Read his post about the best tools for your site (which is secretly just a post about paintballing). Do it now. You can thank me in the comments.

Close to 8,000 words on my story-thing…when I hit 30k or so, I’ll stop calling it a “thing”…

Slow progress

A while ago I wrote about slowing down.  What could be slower than a few days camping in the desert?  No internet, the phones died our second night there, nothing to actively distract or divert.  In my last post, I wrote that I hoped the process of slowing down my internet (and media) consumption would spark some creative juices.  Well, this post is to say that it worked.

While we were there, I started developing an idea for a story unlike any other story I’ve ever tried to write.  I’ve always written contemporary, urban fiction or else sci-fi tinged stories — this would be a fantasy story/novel/whatever.  I have a lot of ideas going into it that are unlike anything I’ve ever seen in most fiction, let alone fantasy stories.  And it features a character I know I can write about because it’s based on someone about as near and dear to me as anyone can be without being me — my wife.  It’s still pretty rough, and I’m just getting started, but I’m pretty excited and I’ve been making it a point to write at least a little each day.

On a related note, here’s another article about the Slow Web movement, courtesy of @photomatt’s blog.  The Slow Web, Jack Cheng.

Programmatic poetry

I was working on a WordPress plugin today that will allow users/developers to stop a javascript from running on a particular page.  That doesn’t sound very exciting, but it got me thinking about the WordPress adage “code is poetry”.  (Blame this on my recent initiative for going slow — I had this idea when I was taking the dog outside…)  I was thinking about the thought process behind that, about how good, semantic code should have a flow and be easy to read and understand.  The tabs and spaces certainly hint at poetry, but what if you took that a step further?

This led me to an interesting idea (hark!): what if you actually wrote poetry like code?  What if you wrote a story/novel like code?  Here’s my line of thinking…

There is a flow to writing code.  Often times it’s written in a quasi-stream-of-consciousness style as you add new functions as you think of them and are testing your program.  You’ll write a function that will tie into another function and call another function.  There are variables that come in and out of different functions and perform different actions.  When the code is complete, you have a finished product that can be executed and enjoyed.  There are parallels in storytelling.  Functions are storytelling elements — plot arcs, story lines, relationships — that tie into other functions (plot arcs, story lines, etc) and involve many different variables.  A variable in programming is a placeholder for a specific object (unit, text string, array of values) that holds a value that can be referred to later.  Variables can be static or they can be changed as new variables or values are added to them (or removed from them).  Variables, therefore, can be characters (or, possibly, a family of characters).

Here’s an example:

function story() {

    // introduce three main characters as global variables
    $tom = 'main character';
    $bill = 'friend of tom';
    $sally = 'love interest';

    function tom_flashback() {

        globals $tom, $bill, $sally;

        $sam = 'father of tom';
        $room = array($tom, $bill, $sally);

        function childhood($sam) {

            bad_stuff_happens($sam, $tom);

        }

        if ( in_array($room, $sally) ) {
            argument();
        }

        while ( $sam != 'deceased' ) {
            $memory = childhood($sam);
        }

    }

}

…and so on.  What it becomes is a dynamic story outline that can continually be added to — new characters introduced, new plot lines added — in a non-linear way.  PHP (which I’m basing this from, but you could conceivably translate this into any programming language) is read from the top down, but in execution, it can jump around.  For example, tom_flashback would happen whenever that function was actually called.  The memory of bad_stuff_happens in $tom‘s childhood only persists as long as $sam is alive.  The argument() only happens when $sam and $bill are both in the same $room with $sally, in which case it’s always the same old thing (presumably there’d be a love_triangle() plot point in there somewhere).  So you’d build out this non-linear narrative, and maybe just write out the argument() portion.  Then later you could flesh out the $memory of $tom‘s childhood().

As a user, you’re typically unaware of the programming language under the hood, so none of this pseudocode would ever manifest in any way into the actual story.  When you go to finalize your story, you would piece together these different functions based on how they actually execute (e.g. the function is called), but when you’re writing it, you might write from the top down.

I’m interested in this idea because it’s absurdly nerdy and also because it is an actually feasible and functional method for outlining a story that could be as epic or as minor as you want it to be (but it seems like it would lend itself better to the epic side of things).  It also would allow you to focus on scenes rather than trying to conceptualize the entire story, so you could really just worry about certain parts and then piece them together later (when all the “functions” were written).  The only prerequisite, of course, is that you’re familiar enough with coding that you could write pseudocode all day long like the above.  Syntax errors don’t really matter, of course, and no one (other than yourself) is going to know if you never finished that bad_stuff_happens function, but the beauty is that you could continue to add to the “code” and just call that particular function much later in the story().

Anyway, that’s my brilliant new idea for a writing method.  I’d be interested in anyone’s reactions or suggestions.  I may or may not start using this for my own writing.