Why writers need Lego

We’re now coming to the end of my son’s two-week Easter break from school. We went on a train, saw the animals at the zoo, and played soccer. Most of all, though, we’ve made things with Lego.

Lego truck

At my parents’ house we dug some old Lego out of the attic. I enjoyed looking at the catalogs from when I was a kid. Strangest was a leaflet from 1973 that would have been packaged with a Lego kit that belonged to one of my older brothers. In sober, Nordic wording (that didn’t quite translate into English) the Lego company explained to parents how their product was an educational tool that promoted hand-eye coordination, planning skills, and creativity. I’m sure it does all those things…

But that’s not why I build with Lego.

Time machine control room

When I worked in the software industry, I used to train and audit development teams to be creative in their designs by using an appropriate mix of throwaway and evolutionary prototyping. That’s just a fancy way of saying the software teams learned to start off projects straight away by building things, and rebuilding, and rebuilding again… The idea is that you’ll end up with a better product by making things and learning from doing, than kidding yourself that you can design everything on paper before you start coding. Sometimes they would make something quickly just to prove a concept or try out an idea, and then throw that design away (but retain what they had learned).  That’s throwaway prototyping. It’s easier with Lego because I don’t get the commercial people complaining I’ve ‘wasted’ tens of thousands of pounds building prototypes that I’m throwing away.  With evolutionary prototyping, you’ve got a slightly clearer idea of your overall design (although many of the details might still be fuzzy) and you build the next bit and the next bit until you’re done. If you realise you’ve stumbled across a better design, you just unpick a few steps and rebuild. The only difference with throwaway prototyping is that you keep you design robust.

This idea of starting off by writing, and only later stepping back and thinking about what you have learned from the process before beginning to zoom in on a final design, is common to writers too. Christopher Priest wrote an article in the current BSFA Focus magazine. He didn’t use software or Lego analogies, but he argued — actually he insisted — that once you’ve finished your first draft of a novel, you should learn what you can from that throwaway prototype, and then set to writing the novel again all the way through from beginning to end. Iterate until you reach a draft you’re satisfied with.

Prototyping isn’t as easy as it sounds. It’s easy, for example, to start off writing a throwaway prototype but then yield to the pressure to deliver it to the publisher as a finished draft. Could making things with Lego be a good exercise to learn agile development techniques for coding and writing books? Probably…

But that’s not why I build with Lego.

In my writing group, if the layout of a scene isn’t clear, our members will ask the author to go away and sketch out a plan of the setting before recrafting the scene in a more vividly realised (and consistent) location. When I get stuck describing a setting, I normally use pencil and paper, but Lego might be an excellent alternative, especially if drawing plans and elevations aren’t your thing.

Perhaps… maybe… probably… but that’s not why I build with Lego.

My reason is because it’s fun. Whether you’re a writer of science fiction adventures or a columnist for the New York Times, you got started down that road because you got a kick out of being creative. For that matter, you could be a cover artist, or developing software for the next generation of consoles, you’re creative — give yourself permission to go have fun creating!

So much of the time, writing is about editing, pacing, consistency, honing, and chasing down that one mis-spelt word that will create such a bad impression that it ruins the other 95,000. It’s worrying about how you’re going to promote your book, whether the characters are credible yet vivid, and whether you’ve got the science right about what happens when your character takes off her helmet in deep space.

A clown entertaining a stegosaur, yesterday

That’s rewarding when it works. It’s even creative. But it’s not the unconstrained creativity you can get from freeing your brain from its fetters and letting go with Lego. It’s not sprint zero.

Yesterday my son and I were building a dairy farm, complete with cows (with udders!) and a milking parlor. This morning we added a time machine to the farm, upgrading it from a dairy farm to a dino-dairy farm, and we’ve now transported our first set of dinosaurs through time to our farm.

Milking time at the farm. Moo!

It doesn’t matter if the bricks aren’t the right colour, or the cows don’t have tails, because we’re letting go and having unconstrained fun.

Well, that’s not quite true. We did have an incident where a pterodactyl ate a farmer and I made the mistake of calling the pterodactyl a dinosaur, an error which my son was eager to point out. (“They aren’t dinosaurs! They’re flying reptiles, Daddy.”)

In fact, becoming a parent has convinced me in recent years that we are all of us creative; it’s just that some of us forget, and a lucky few get paid to be creative.

So plan out the scene in your book, or model the bridge you’re going to build, have some kids… do whatever it takes to give you an excuse to let yourself with Lego.

You deserve it.

Predator X

UPDATE: April 18th

Another writing analogy comes to me courtesy of author, Ian Watson. He told me recently that when editing a novel, if a scene needs more than a few lines of change then you should rewrite it completely. Otherwise it’s prone to mistakes and inconsistency, and the prose becomes unfocussed because the scene wasn’t written with a coherent vision.  That’s what I’ve been arguing in software terms for years. These days we’d call it code refactoring. Software code that’s been changed, and changed, and changed, is code that becomes brittle and is likely to break, especially in large, integrated sytems where the code unit you’re tinkering with not only has to do it’s own job well, but has to co-operate with all the other code units, which are also being tinkered with. Sometimes it’s called spaghetti code.

It’s interesting that I hear the builders of prose argue for quality with a more powerful  voice than builders of software code. In real world software projects, there is often a strong pressure not to refactor code from the commercial part of the organisation. We can’t afford the ‘luxury’ of refactoring, is a common argument. If we refactor then we’ll miss our deadline, is another. In my experience, the code writers have a much weaker voice than the prose writers, which means code is delivered that might work (mostly) in the short term but isn’t robust and will eventually break. (And just to balance that comment — and give a hint at how running software organisations isn’t easy — there are plenty of coders, as well as writers, who will use concepts such as refactoring as an excuse to permanently tinker and evade committing to a release.)