Why we run monthly hackdays

This is part of a series where we share how we work at LloydsDirect.

Which is faster: your fingers or your brain? By which I mean: which limits how quickly you work, how fast you think or how fast you type? This is a debate that Chris, a fellow software engineer, and I used to have.

While I certainly am not a fast typist (my style might be described as influenced by touch typing but using a total of four fingers and a thumb), I always held that it is our thinking that is the limiting factor in how fast we work. (Chris, obviously, held the opposite view.)

Now, I can speak a lot faster than I can type — and speaking requires thought — so arguably this proves that Chris was right, but my point is that when I write — prose or code — formulating the idea or the approach takes more time than typing it.

Why is this? What is it that slows us down?

Shush, inner critic!

One limiting factor is your inner critic. It constantly second guesses whether what you’re doing is correct or “good enough”.

“What will so-and-so think of this? Will this perform under load? Didn’t I read somewhere on the internet that strings assigned using single-quotes are faster than those delineated by double-quotes?” On and on my inner commentary runs (in this example when I’m writing code).

The inner critic plays a valuable part in the creative process — it looks after quality control for us. But if this voice is too loud, it drowns out other thoughts, becoming a drag on forward progress. Have you ever found yourself writing a sentence (or a line of code) only to delete it immediately? That’s your inner critic at play. It’s hard to make progress when each step forward is immediately wiped out.

Writers have long known the solution to this problem: first write, then edit. When it’s time to create something new, the trick is to intentionally ignore your inner critic. Leave the critiquing for later.

So if writers are so clever that they’ve figured this out, what else can we learn from them?

While I’m using my experiences as a software engineer in this post, we all have inner critics, and overcoming this applies equally to design, data and product.

Start anywhere…

Some authors start by outlining their novels. They know how it will end before they start writing. Other writers take a totally different approach. In On Writing, Stephen King says he starts by imagining a scene, how it would feel, what makes it so tense, etc. Then he asks what has happened that led to this scene.

Jokes are told about the apocryphal developer who starts at the beginning of the file and keeps coding till the end of the file. But I’ve met developers who work this way.

This way of working might sound like a terrible approach, but people are different, with different ways of thinking, so advocating one way over all others isn't very helpful. Some of us need to feel our way into a problem. If I start by trying to figure out the perfect structure or architecture, I just end up spending a lot of time staring at a blinking cursor on a blank screen.

It’s useful for me to know that I find starting difficult: if I give myself the freedom to start wherever feels opportune, I can avoid sweating over whether this is “correct” and just get into it.

…but throw it away

However, this does require you to be wary of falling in love with your first attempt. Without any advance planning, you’ll inevitably make some poor decisions along the way. And because we humans are incredibly loss averse, we really struggle to “throw away” work — even if we rationally know what we’ve done is not quite right.

So, if we can steel ourselves to the fact that we might make a few wrong turns and have to discard some work, we’re still better off just starting. In fact, my high school composition teacher used to have a rule: “Delete your first paragraph, it's almost always unnecessary.”

I think more cycles are burned hemming and hawing than it takes to write the code that gets deleted.

Our brains are fabulous machines in this way: once primed, they keep working on the problem, almost as if running as a background process. That’s how I think about any “warm up” code — it’s disposable and valuable not as the finished product but rather as a jump-start for a vehicle for learning.

Hackdays train different muscles

So how can we make use of this in our work? At LloydsDirect, every third Thursday of the month is a hackday.

Hackdays are an opportunity to change the constraints under which we work. When writing production code, we expect software engineers to consider every case, cover every eventuality, write tests for everything, plan for scale... the list goes on. When hacking we can build only the happy path, ignoring all the gnarly edge cases.

Boshing something together is an amazing way to learn where the boundaries of a problem lie. This is the proof of concept approach. Sometimes the fastest way to learn about a problem is to just get your hands dirty and build something.

Hackdays are also a perfect way to practise silencing your inner critic. Trying to build something in just a day is really hard, and it forces you to be radically economical on what parts you actually build and what parts you cut, cheat, or fake. You don’t have time to make everything perfect so you have to get comfortable with showing your slapdash code, blemishes and all.

Learning how to do this allows you to explore (and discard) more approaches, faster. And becoming okay with throwing away code is liberating!

It’s about the journey, not the destination

Hackdays or hackathons can be a great way to come up with new ideas for products or features. Twitter and Zapier famously originated from hackdays. While we do occasionally theme a hackday around a specific problem or area of innovation, this is the exception rather than the rule. There’s only one rule that’s constant for us: demo your work, whatever state it’s in, the following morning. This helps emphasise that hackdays are about the journey, not the destination. The goal is to stretch yourself to see how far you can get in a day, not to produce something that can be released into the wild.

I won’t lie: over the years, our hackdays have produced more than a few tools or features that we’ve put into production. While this can be amazing — getting something useful built in a day is a thrill! — this has a downside: once you start relying on something, you’re stuck with it. And relying on (and maintaining) something that was literally hacked together in a day is not fun.