Montage-Driven Development

Bear with me a moment: I’ve got a theory.

Every so often, Hollywood comes up with a movie which involves programming or hacking. When it’s good, it’s great, and we get to see genuine code in Mr Robot or The Social Network. When it’s bad, we get someone unplugging a monitor to turn a computer off (points to Into the Spider-Verse for “we don’t need the monitor”).

So what’s it like for someone working in the tech industry to be surrounded by the glamorised version of your job?

There’s plenty of humour. When film and television portray things inaccurately, it’s huge fun to point out the flaws and how vastly different it is from reality. Software engineering is hardly the only industry for this — I thoroughly recommend the Inappropriate Gavels Twitter account for an English legal insight.

When it’s portrayed well, then some of it is exciting and motivating. Do I like the idea of being one pounding techno soundtrack away from creating a piece of software that changes the world? Absolutely! I can come out of a cinema absolutely driven to build something new. Of course, I then need to spend a few hours finding exactly the right soundtrack for my coding binge, what I’m going to build, and messing about with a design that I can’t quite get right.

What’s really missing from all of the portrayals of coding is the collaboration: the discussions and decisions and questions, and learning. It’s difficult to create a soundtrack for two people writing tests so that they can be sure their code works in the future. It’s even harder to convey someone scratching their head for an hour to discover the code was broken because they missed out a semicolon.

Building code that works and ships quickly (by which I mean within weeks rather than within a three-hour runtime) is hard. It can be fun, but it can also be laborious and complex. When everything is going well, a team works together and relies on each other, constantly helping one another out. None of that is as cool as a six-monitor setup with neon glows and quick cuts between four different angles of someone’s touch typing.

What we’re left with is what I’ve often called “Montage-Driven Development” — the idea that a programmer with a sufficient supply of caffeine and a sturdy pair of headphones can miraculously produce perfect code. This puts an enormous amount of pressure on an engineer, given how complex code can be, so we try to mitigate it by saying that they mustn’t be interrupted, which just compounds things. The sheer frustration of your train of thought being broken is neatly summarised by this viral comic. I once worked in an office where someone suggested engineers have traffic lights on their monitors indicating whether or not they could be interrupted (mercifully never implemented).

Having that level of focus is great for a time, but there’s far too much pressure alongside it. Truly great work comes from a team, not an individual. Aside from the lottery factor (what would you do if someone on your team won the lottery?), it isolates people. If someone has a problem they’re stuck on, they’re a lot less likely to ask other people how to solve it if everyone has headphones on and their heads down.

I love a good movie, and Hollywood is much better at portraying technical detail than it used to be. There are also fascinating explorations of the moral implications of AI or the pressures of a start-up. But they’re not building real software.