Designing with Code: The Most Important Career Decision I Made

In 2004, I finished an Industrial Design degree and immediately started looking for work in graphic design. I’d recently moved countries, had no professional network to lean on, and needed some way to make myself visible. At the time, that meant building a website.

Today that sounds trivial. Back then it wasn’t. There was no Webflow, no Squarespace, and WordPress was still in its infancy. If you wanted a portfolio online, you either paid someone to build it or learned enough HTML and CSS to make it yourself. So I opened a text editor and started teaching myself how websites worked, not because I had ambitions of becoming a developer, but because I needed a job.

I learned the way most people did at the time: by breaking things repeatedly. I copied snippets from other websites, viewed source code obsessively, experimented with layouts, and slowly pieced together enough understanding to publish something online that looked vaguely professional. It was rough, but it existed, and that alone created opportunities. That first website led to freelance work, the freelance work led to more projects, and before long I was operating a small independent design practice largely because I’d learned enough technical capability to make my own ideas real.

Looking back, learning code was probably the most important professional decision I ever made, though not for the reason people often assume. It didn’t matter because it turned me into an engineer. It mattered because it fundamentally changed how I thought about design.

Industrial design had already taught me to think systematically. You learn quickly that objects don’t exist in isolation. Materials, manufacturing, ergonomics, constraints, cost and behaviour all shape the outcome. Graphic design introduced another layer: communication, hierarchy, typography and visual clarity. But the web introduced something different again. It introduced interaction.

For the first time, the things I designed could respond. Layouts could shift. Interfaces could guide behaviour. Feedback could happen in real time. The work no longer existed as a static composition sitting on a page. It unfolded through use. That changed the questions I started asking as a designer.

How does this behave when conditions change? What makes an interaction feel intuitive rather than irritating? Where does friction appear? What creates momentum? What reassures someone they’re moving in the right direction? Those questions simply don’t emerge in the same way when you’re designing static artefacts.

Once I became comfortable working in the browser, I gradually stopped treating design and implementation as separate activities. In many cases, I stopped using Photoshop altogether and designed directly in HTML and CSS because it gave more honest answers, faster. You could immediately see whether a layout survived different screen sizes or collapsed under pressure. You could test the pacing of interactions instead of describing them hypothetically in annotations. You could feel whether something was clear, awkward, heavy or effortless through use rather than speculation.

That process reshaped my understanding of what digital design actually is. A surprising amount of the industry still treats design as the production of screens, but screens are only snapshots of behaviour. Real products exist in motion. They exist in transitions, responses, edge cases, loading states, interruptions and flows between actions. The browser forced me to think about those realities much earlier in the process.

It also removed a great deal of friction professionally. Conversations with developers improved because I understood the constraints they were working within. Ideas moved faster because I could prototype them myself instead of waiting for implementation cycles. Stakeholders responded differently because they were reacting to something functional rather than interpreting static visuals. Over time, that capability naturally pushed me into broader product, systems and strategic work because I could move between concept, interaction and implementation without much translation overhead.

Twenty years later, I still think many designers unnecessarily distance themselves from the material they work in. Digital design is ultimately shaped through code whether designers engage with it directly or not. That doesn’t mean every designer needs to become an engineer, nor do I think the industry benefits from pretending disciplinary boundaries don’t exist. But I do think there’s enormous value in understanding the medium closely enough to think realistically within it.

That matters even more now than it did in 2004. Modern products are dynamic systems, not isolated pages. Design systems increasingly function as codebases. AI can already generate competent front-end scaffolding in seconds. The value of a designer is becoming less about producing polished static artefacts and more about understanding behaviour, structure, decision-making and experience quality deeply enough to shape outcomes coherently.

Learning code helped me make that shift earlier than I otherwise would have.

I didn’t learn it because I loved programming. I learned it because I needed to survive professionally in a market where nobody was going to hand me opportunities. But in the process, it changed the way I approached design entirely. It pushed me closer to the reality of how digital products are actually made, and I think that proximity made me a significantly better designer than I would have been otherwise.