Explorers and Architects

There is a famous concept in the writing community, sometimes seen as a grand divide which splits all writers into two opposing camps, which I think applies to programming as well.

Before we start, it’s important to note that reality is nuanced. These camps are the extreme ends of a broad spectrum, and most people belong somewhere in the middle.

The most common terms for these two camps are architects and discovery writers. Since I’m a writer at heart, this mixed metaphor really grates on my nerves—I always refer to them as architects and explorers instead.

Architects are people who plan ahead. They draw up their grand design, perfecting every last detail before they ever put pen to paper and write some prose. If the design doesn’t work when confronted with reality, they go back to the drawing board and fix the plan itself before continuing.

Explorers are people who go on an adventure without even the barest sketch of a map. They set out from their starting point with no clue where their story might end up, and every step along the way is as much a surprise to them as it is to their readers. If they get stuck, they retrace their steps and try a different road.

It’s important to note that these approaches are equally valid. Both can produce incredible stories, and with a little work on either side you can barely tell the difference between the two when looking at the end result.

To give a couple of well-known examples, one author who is particularly outspoken about being an explorer is George RR Martin, while another who is well-known to be an architect is JK Rowling. You can see how their different approaches colour the way their stories are told, yet both writers have written incredibly successful and well-loved stories.

And, as mentioned before, in reality most people blend the two approaches together.

So how does that apply to software?

Generally speaking, engineers are given a set of requirements or a problem statement (or freedom to find their own), and asked to build something which works.

Many engineers like to plan first. They start by sketching diagrams on a whiteboard, then perhaps design an interlocking system of types which define their chosen interfaces, and then write the code which actually implements their solution.

Other engineers prefer to dive straight in to the code. They explore the problem space via experimentation with real code, false starts, and intuition, and then refine their path and build up a more robust and clear solution over time.

Again, many people are a mix of the two. It’s common practice to explore the problem space first, then throw away the exploration code and architect a more permanent solution based on the insight gained.

In spite of this, in my experience people often assume that programmers are architects first and foremost. That assumption then leads to miscommunication.

Interestingly, one person can sit on different sides of the divide for different things.

When writing fiction, I’m at the extreme architect end of the spectrum. My wife and I spend a lot of time planning and fleshing out the details of our stories well before we ever put pen to paper.

When writing code, I tend to lean towards the opposite. Without exploring the problem space by experimenting with real, working code, it’s hard for me to even get started.

I’ve had to explain this to people in the past to help them understand the way I want to work, and every time it’s been a new idea to them—even if they’re explorers themselves.

It also presents a slight problem in interviews. You often see interviewers state that if you don’t plan your solution before diving in to code, they will mark you down. Most interviewers are understanding if you tell them at the start that you approach things differently, but to do so you have the be aware of the difference first!

The key is that, as with writing prose, the different approaches to writing code are equally valid. Discussions in the programming community often devolve into opposing tribes who just talk across one another. Could it be that this unacknowledged divergence contributes to that tendency?

As an example, consider TypeScript. Many people in the web community are enthusiastic about it; others remain skeptical, even after giving it a chance.

For me, the experience of writing TypeScript directly conflicts with my explorer tendencies. For other explorers, it can become part of their discovery process. For architects it’s often the most natural expression of their thought process.

Discussions around TypeScript often ignore this nuance, and instead imply that what works for one set of people should automatically work for another.

If we recognise that different people approach programming in fundamentally different ways, we can try to understand those differences. Perhaps then we can have more productive discourse more often, and better grow as a community.