The issue that came up in the coaching session was: when to stop meeting and write some code? My client, a senior software engineer, knew in his bones that more meetings wouldn’t move the project forward, but a week of him coding a prototype would. But how to communicate that without appearing to just arrogantly blow off the team?
“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 – which means a defeat for somebody.
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.
I was working with a young entrepreneur a few years ago, 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 and build on 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 some 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. It doesn’t mean that the wider team is 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.
So how to communicate this to the team? 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, but 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 how to move forward”. 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.