Yes, Code Wins Arguments. But Why? (And How to be Polite About It).
OK, so when to stop meeting and write some code?
This came up in working with a senior software engineer recently. He had diligently gone to the project meetings, tried to move things forward, tried to drive consensus, but things were stuck. He knew in his bones that more meetings wouldn’t help, but a week of him coding a prototype would. But he didn’t want to “take the project away”, or appear arrogant and pushy. (All good concerns…).
What to do?
“Code Wins Arguments” has been around for a while. This is from the Facebook S1 filing:
“Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works”.
Classic! “Hackers would rather…”. Of course they would! No more stupid meetings, we’re just going to build it and you guys can sort it out later! Cool! The implied context is an argument and the outcome is a win for the hackers — which means a defeat for somebody else.
Here’s the thing though: “Code Wins Arguments” is short-hand for a much more subtle process. Software is a creative act. When we’re thinking about building a piece of software, we don’t know how it’s going to turn out. We really don’t. We can speculate, sketch potential structures and collective outlines of what we think we’re going to build, but until we start to build it, we won’t know.
The best way of putting this came from a young entrepreneur I was working with a while ago. We were staring at a design for a new product. It looked good, but something was bothering both of us. Finally he said: “we need to build it. We don’t know what it wants to be yet”.
In every creative process I know, there is a balance between the fine, subtle details of the actual work, and the elegance and structure of the final goal we have in mind. They inform one another. You can analyze the structure of a Mozart symphony all you want — if you don’t have Mozart’s command of the details, you ain’t gonna write one. And if you start a novel or a software project without a good idea of the structure, once you get about a third of the way in, you’ll find yourself in a tar-pit — too many possibilities, too many threads that don’t tie together. A mess.
So the phrase “Code Wins Arguments” is, I think, blunt engineering short hand for “we need to go and create now, and see what this thing we’re building wants to be”. It’s a necessary step in the creative process
It does mean that for some period, the project is no longer a team sport — it’s in the hands of a few (maybe one) engineers. So there’s some letting go necessary here. The rest of the team has to understand that the product won’t show itself until some code gets written.
But it’s also true that the wider team isn’t out of the picture forever, or loses ownership. The step after coding a prototype is getting back together, seeing what’s beginning to show itself, and fit it into the wider structure of the business.
Ideally in a software company, the idea that software needs periods of “just finding out” is baked in. If so, great. “We need to go and code our way through this” is an accepted stage in the process. If not, you need to get there — change the culture, which we know takes a while, and a lot of repetition.
So how to communicate this to the team? How could the engineer I was working with get out of the jam?
Well, we can ask the Magic Question: “what do they want?”. My guess is they don’t want to sit in fruitless meetings for hours. My guess is that they would like the project to move forward, like, now. My guess is they don’t want to lose ownership. So, communicate a solution: “in a week, I can show you a prototype that does X and we’ll know where to go”. Or: “in two, this feature will be up and running and we can see if anybody wants it”. Time-box it, make it clear it’s an exploration and that it supports the project as a whole.
“Code wins arguments” implies an argument and a defeat. “Code moves us all forward” might be a better, although less pithy, approach to bring to the work.
Software is a creative process. Sometimes it needs to tell us what it wants to be. Your development culture needs to acknowledge that.
