What is programming like?

We in the software profession have done a terrible job of explaining to the public what it is that we do. Everyone has interacted with a teacher or a doctor. There are TV shows about lawyers, cops, even government officials. However warped our impression of their day-to-day, we can relate to these professions. TV depicts programmers as modern-day wizards, socially aloof, hacking into systems or bringing the new algorithm online just in time to stop the cyberterrorists — totally disconnected from people’s experience of the software they use every day. Software remains mysterious.

This isn’t just a problem for awkward “so, what do you do?” conversations at parties. I believe one reason why so many demographics are underrepresented in software is that unless you grew up with it, you’re unlikely to have the faintest idea what making software is actually like. Why would you strive — particularly against economic obstacles and systemic biases — to enter a profession you know nothing about?

Programming sucks

Inspired by a friend who couldn’t see what was so hard about programming, Peter Welch wrote a hilarious, heartfelt and all-too-true rant about what writing software is like. His title, and answer: “Programming Sucks”. The whole, long post is enjoyable reading, but here’s a representative excerpt:

Imagine joining an engineering team […] for a bridge in a major metropolitan area. […] The bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. […]

Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn’t.

Welch brilliantly describes the nuances and stresses of trying to cobble together something useful, based on a blueprint nobody bothered to draw, out of parts designed to do almost, but not exactly, what you need them to do.

Reading this, I immediately wanted to send it to every friend and family member to whom I’d failed to explain what it was I did all day. But I didn’t send it, because it only tells part of the story. Programming sucks, so why do it?

For me, it’s because programming is amazing.

Why we do it

Programming is like building structures out of Lego, but I never run out of Lego bricks, and if there’s no brick with the exact shape that I need, I can make that brick. I can take the structures I build and use them as bricks to build bigger, more ambitious structures. I can build tools out of bricks to help me build quicker. If I build a model city, or a crane for building model cities, I can offer them to millions of people to download and play with, in any part of the world.

Lego city

Fred Brooks wrote in The Mythical Man-Month:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms.

One of the most liberating things about writing software is that the tools you use for it are also software. Remember that Lego tool you could buy to help you pry bricks apart? Imagine if you could build that tool out of Lego bricks. We can use the skills we have for writing software to improve the tools we work with. We can write software that makes us better at writing software.

There is a dark side, as Welch entertainingly describes. There are deep, scary flaws in the tools and processes we use to build software. Everything is more difficult and arcane than it should be. We spend so much effort, after the software is “done”, fixing problems that should never have been possible to introduce in the first place. Sometimes it’s amazing that anything ever works. But somehow, it does, and so we have smartphones, and Angry Birds, and the Internet. Programming sucks, but look at where we are!

Programming gives us live video conversations with relatives around the world; a map of our own biology; widgets that monitor oil pipelines from the inside; spreadsheets that run entire businesses; games where you build cities, or pretend to be a goat.

Of course these are specialised fields, each with its own demands and disciplines, but they all start with writing apparent gibberish in a text editor. The reach and breadth of what you can do with gibberish is remarkable.

Castles in the air

Programming sucks, but for me, that is cause for tremendous optimism. We can use programming to improve programming! We can reduce the complexity that programmers have to keep in their heads. We can make more visual, interactive, intuitive tools for understanding the behaviour of programs. We can make it easier to fix incorrect programs, and easier to write correct ones. Programming is only going to get easier, and more powerful, and more accessible.

If we’ve come this far — in the 60-odd years that programming has even been possible — while programming sucks, how far can we go when it doesn’t?

Brooks’ phrase “building castles in the air” was once used satirically, to mean chasing an impossible dream.

For me, that’s what programming is like.

Thanks to Joseph Chow, Lily Han, Conrad Irwin, Martin Kleppmann, Lee Mallabone and Kiran Prasad for reviewing a draft of this post. Their feedback improved this post immeasurably.

Lego photo credit: dunechaser