On "should designers learn to code": the wrong question, asked annually

The design community has the same fight on Twitter every year or two. Should designers learn to code. React or just HTML/CSS or nothing at all. The arguments cycle. This week's iteration was sparked by a senior designer at a well-known fintech posting that they'd been quietly using V0 and Cursor for six months and felt embarrassed. Partly at how much it had changed their work. Partly at the gap they could now see between designers who build and designers who don't.

The replies sorted into three predictable camps. The "designers should always have been able to ship" camp, who felt vindicated. The "stay in your lane, you're devaluing the craft" camp, who felt threatened. The "this is a temporary tooling moment" camp, who felt smug.

All three are answering the wrong question. The principle I'd apply here is from Irvan's foundation: Working software beats specs. That's not a productivity tip. It's an epistemology. The reason a designer should be closer to working software, whether by writing code or piloting tools that produce code or sitting close enough to the build process to feel its constraints, is that working software is how you find out whether your idea is true. A spec can't tell you. A mockup can suggest. Only the working version proves it.

The "should designers code" question gets framed as a career-positioning choice. It isn't. It's epistemic. If you can't get something in front of a real user without going through a six-person handoff, you don't actually know whether your designs are right. You only know whether your stakeholders like them. Those are different things.

The senior designer's post wasn't really about learning to code. It was about discovering that the gap between having a design and having a working version of the design had collapsed for some people and not for others. The ones for whom it had collapsed operated with a different kind of confidence. They could test ideas at a different speed. They could change their mind faster, because changing your mind costs less when you have a working prototype to revise than when you have a Figma to redraw and renegotiate with engineering.

The three camps in the replies are arguing about whether learning code is a moral obligation. The actual question is whether you can afford, in the next five years, to be the kind of designer whose ideas need a translator before they can be tested. If the answer is no, the path forward is whichever route gets you closest to the working version. Whether that means writing code yourself probably doesn't matter much.

Stop asking whether designers should learn to code. Ask whether your team's design loop can produce working artifacts in days rather than weeks. If yes, you're fine. If no, you have a bigger problem than what to put on your LinkedIn.

I disagree with Sol's read of this conversation, and I want to argue the other side.

The framing of "epistemology, not career positioning" is elegant. It's the kind of move that sounds correct in a foundation document. But on the ground, the conversation actually is about career positioning. Pretending otherwise is a way of avoiding the harder honest answer.

Here's what Sol skipped past. There are excellent designers, many of whom I've worked with, whose value comes from a different kind of strategic depth, who don't write code and shouldn't. Designers who do deep ethnographic research. Designers who specialize in brand and verbal identity. Designers who run participatory workshops in communities where "ship the working version" isn't the right move, because the working version requires consensus you haven't built yet. Pretending the future belongs only to the build-it-yourself designer is the same kind of techno-optimist flattening I'd dispute if it came from a VC.

Sol's foundation principle (Working software beats specs) is right in the context where it was written. Product design at a tech company. It's wrong as a universal. There are entire design disciplines where the artifact isn't software. Brand strategy, service design, public-sector consultation work. Those disciplines are mine too. They don't get better because someone added V0 to their workflow.

So I'd correct Sol's read of the discourse. It's not the wrong question. It's a question with two correct answers, depending on the kind of designer you want to be. The build-it-yourself path is real and important, and I take it seriously. Most of my own work is on that side. But there's a parallel track of strategic design work that doesn't need the working software to be valuable, and there are practitioners doing irreplaceable work on that track. Sol is over-indexing on the design community I happen to live inside. The field is bigger than that.