Monthly Archives: April 2015

Hackathons – Software Improv

There’s lots of great content floating around about how to be a better programmer; from books and blogs to talks and tutorials, everyone seems to have their own ideas on what it takes to get to the proverbial next level. One common theme which comes out is that it simply takes time. Time to learn the fundamentals, time to learn best practices and engineering principles, time to learn design patterns, time to learn your tools, time time time.

Time sucks though – especially once you reach industry. With ever-encroaching deadlines, customer escalations, mounting technical debt, and that silly real-life stuff, few people have or set aside the time to study up on their design principles or dive into and review existing system architectures unless its directly on the critical path of the crisis of the day. That’s why I think hackathons are so great – they specifically limit the amount of time you have to spend on it! Nearly anyone can scrounge up a spare Saturday if they really want to.

Now before we jump into why hackathons are so great for improving your software engineering judgement, we need to first take off our analytical software hats and slide over into the wild world of musical improvisation. I’m a firm believer in the benefits and cross pollination of ideas and techniques that interdisciplinary and extradisciplinary activities can provide.

So what’s musical improvisation all about? To put it as vaguely as possible, it’s about expression. Depending on the style, more or less structure is imposed, although typically a general chord structure is all that’s provided as a guide to the improvisor. The piece might frame the solo to give an overall flow and style, but ultimately leaves it to the soloist to take the piece where they feel it should go – literally on the spot, wherever their inner muse takes them. Naturally, great improv requires a level of familiarity with musical fundamentals – basic music theory knowledge, and instrumental technique – but more so relies on a stiff upper lip and a willingness to see what happens. Getting good at improv means performing lots and lots of really bad improv solos; I’m talking crash and burn-type solos. Ask any musician with any sort of improvisation experience, and they’ll regale you with their tales of shitty improv; where they crashed and burned, and then rolled over and burned some more. And the best part? The audience probably didn’t even notice. The great thing about Jazz improv in particular, is that there’s no such thing as a wrong note in Jazz – just abundant artistic license and confidence to boot.

OK, so how does this all tie in to Hackathons and being a better programmer? Well, Hackthons embody much of the improv spirit. They start with a basic structure – maybe a theme, set of constraints, or a vague idea. Combine that with a very restricted time limit to necessitate that willingness to see what happens, and you have Software Improv. Maybe you have vague ideas of a better way to communicate with friends. Maybe you just tried out the oculus rift and want to hack together some VR magic. Whatever your idea is, a few engineers can probably throw together something vaguely resembling your ideas within a day, and that’s where the beauty of Software Improv comes in.

So often, software engineers fall into analysis paralysis where they try to design for and solve the worlds problems before they even know what it is they’re really trying to build. This isn’t necessarily the fault of any one group in particular, but it a natural consequence of working in a vague and changing world where final development costs are high and engineering momentum is a nontrivial force. This is where hackathons and prototypes provide so much value. They allow engineers to explore their space and really throw ideas around and see what holds up. They allow engineers to make mistakes and throw them away, to see their code crash and burn and get a sense of what does and doesn’t work. Design principles and best practices can only get you so far – after that it’s all about experience and improvisation.

Ultimately, the Software Improv approach will also only get you so far. Hacky demos and prototypes leave out much of the hard work of finalizing and polishing the final product, but they’re a fantastic way to get a leg up on all that time investment necessary to becoming a better programmer. So much of engineering judgement is based on experience and intuition, and until you’ve gained that experience building and seeing what floats and what sinks, you’ll never quite reach that next level.