Code-first to product-first

Recently I discovered this article on Zach Lloyd’s website in which he describes two kinds of programmers:

There is the code-first programmer:

[Code-first programmers] are obsessed with how code is architected, what tools, libraries and languages are used, how much test coverage there is – stuff like that. Code-first programmers are psyched when they check in the perfect abstraction, when they get to use the latest language-feature, when they delete dead code. That is, they love the code they write – the code is the thing. — Zach Lloyd

And the product-first programmer:

The product-first programmer cares about that stuff too, kind of, but only as a means to an end. For product-first programmers, the code is the scaffolding, the support, the steel beams in the building, but not the end product. The end product is, well, the product, not the code, and what matters to them is how well that product actually solves the underlying problem. 

Product-first programmers love building and launching and seeing users use what they’ve built. The product is the thing. — Zach Lloyd

Lloyd initially framed this as a dichotomy to make his point, but I think that rather than being one or the other, many programmers fall on a spectrum. And they might slide further up or down the spectrum, depending on the job they are doing or the dynamics of the team they are working on. 

Regardless, these “programmer personality” descriptions articulated something I’ve been thinking about recently. Over the course of my career, I’ve become less and less of a code-first programmer and more of a product-first programmer. When I was younger, I was quite happy to obsess over code structure, being as DRY as possible, chasing the idea of clean, beautiful code, and have passionate conversations with others over what to name things.

These days, the people I’m working with can call that file or function whatever they want. I don’t think the names of things really matter that much. Does the code within do what it is supposed to? Are we moving closer to shipping what our users need from us? That’s what I care about. 

Consistency in naming conventions and code-style is ideal, for sure. My type-A brain likes consistency. But after years of being emotionally triggered by code that doesn’t perfectly fit the rules, I’ve realised what a colossal waste of time and energy that is. Despairing at some code that was written by someone else on the team (or me on an off day 6 months ago) because it looks ugly distracts me from getting what I’m supposed to be getting done right now. So I’ve trained myself to let it go and move on.

I’ve been working on the same code base for almost 6 years now. I’ve taken part in re-writing almost the entire CodePen front-end, some sections two or three times! Every time I’m convinced that this version, these new tools, this new directory structure, these new conventions will be so much better than what we were doing before. And it is an improvement for sure. But I still don’t feel satisfied looking back at that code 2 years later.

In personal productivity, we can get caught up in designing and redesigning the “perfect system” that will make managing our life effortless. We think that when we find the perfect task management app, the perfect review process, the perfect note-taking system, we will feel peace. In reality, the structures and systems can assist us, but we still have to put in the work to prioritise our time and energy, stick to our goals and deal with the messes that are inevitable. Because life is messy.

Chasing perfect code can feel a little like that. It’s easy to think that if you get your style guidelines just right, your directory structure organised perfectly and your test coverage super high, writing the Software will be easy. Your code will look beautiful, the product will be of high quality and you will never ship bugs. It’s an attractive premise, but it never really works that way and you can waste a lot of time chasing the perfect-code-pipe-dream. Time that would be better spent working on what your users can actually see and appreciate.