why I became a designer who codes (translation kills designs)

tech · 2026-10-13 · 5 min

designers who don't code hand off pictures and hope. designers who code hand off working things and know. I chose the second after watching too many good designs die in translation — here is what coding buys the design, what designing buys the code, and where the combination fails.

what code buys design: truth

compositions lie: impossible states, untested lengths, animations nobody timed. building my designs means meeting reality before the client does — the long headline, the empty list, the slow phone. designs that survive contact with the browser ship; pictures that never met one don't. every hour prototyping saves three arguing about feasibility.

what design buys code: judgment

developers optimize for correctness; designers optimize for the person. the combination asks both questions: does it work, and does it feel right? error states with tone, loading with reassurance, forms that forgive — the details pure engineering deprioritizes and pure aesthetics can't implement. two disciplines, one artifact, no handoff losses.

the failures, honestly

breadth taxes depth (my algorithms won't impress, my type kerns better). time splits (two crafts to maintain, both moving). clients miscategorize ("the designer who'll also do the backend/accounting/logo" — no). the answer is scope discipline: I code the frontend I design, and say plainly where the pairing ends. T-shaped beats hyphenated-everything.

FAQ

should designers learn to code?

enough to prototype and converse: HTML/CSS/JS basics change how you design even if you never ship. full-stack is optional; literacy is not.

should developers learn design?

symmetrically: enough typography, spacing and hierarchy to not actively repel. the bar is "doesn't embarrass" — judgment beyond that is the designer's job. both sides meet at the prototype.