Coding for designers

Disclaimer: I do not think there's a singular correct way to do most anything. The content below is not an instruction manual on how I think screen design "ought" to be executed. It's what I've found helpful in my own pursuit of screen design as a career.

Why I learned to code

My pursuit of learning code has been shaped by:

• Relevancy: Everything I design is constructed in this medium.
• Experience: Ideas are always plentiful; great execution is always scarce.
• Capabilities: I can own the entire process of what I do, if need be.
• Future expectations: AI's value is expanding what I can drive and deliver.

The limiting factors in designing "cooler" stuff are usually bandwidth and capabilities. I've always been drawn to the idea of unblocking my own projects from being descoped—whether it's finding viable workarounds within constraints or building something myself. Understanding the medium I'm working with is required.

Most of the web work that impresses me tends to be created by a very capable few people, or one person, with limited input. These people have earned an extremely high level of trust by relying on action and efficiency rather than constant communication. We never share links to Figma files that inspire us. We share websites.

The reality is that most SaaS interfaces are structurally predetermined. A B2B product likely has a left-side nav with page content to the right. A marketing site has a top nav with standard content sections below it. Roughly 95% of the visual design decisions have already been made. The real differentiator is execution—and the details that make an experience feel "ownable" live in interaction, transition, and state. These are hard to even realize in a static tool like Figma, much less represent. To make the things I wanted to make, it became obvious that I had to learn to code.

How I learned to code

I built my first website around 2009 in a high school web design course—Macromedia Dreamweaver, HTML tables, FTP uploads to the school district's servers. After high school, I pursued construction for a few years before returning to technical college for graphic design. By the time I came back, responsive design had taken over and Flash was dead. I had to re-learn how to make things on the internet.

In school, I avoided writing code whenever possible. Tools like Adobe Muse and Webflow let me work visually. I went deep on Muse—sold sites to clients built on it. Then Adobe deprecated it and everything I'd built was going to break. Rather than betting on another platform that might disappear, I opted to write code by hand. Pure HTML, CSS, and JavaScript, deployed through Netlify's drag-and-drop. The code was terrible, but it was mine, and it forced me to learn the fundamentals thoroughly.

Over time, I discovered 11ty and the JAMstack, which finally made Node and build tools click for me. I started building everything this way—and still do. My first full-time website designing/building role was at Abstract (using Webflow), where my understanding of HTML, CSS, and JavaScript made the tool feel like second nature.

The real turning point was joining a startup called Rewatch. My role was to handle everything marketing design related, end-to-end—designing and coding the marketing site from the ground up. The CEO believed that if it lives in code, it should happen in code. Rather than designing in Figma, I designed as I wrote. My manager—a designer who was also a full-stack engineer—showed me the ropes through pairing sessions. Because I was required to work this way every day, it became second nature.

It wasn't until Rewatch that I felt like I became broadly valuable to a company as a designer. The push to take ownership over my work changed how I view my duty in this role. By the end of my time at Rewatch, I could singlehandedly deliver something that had tangible value to a business (and measure it).

Full transparency: at first, it was a lot. I left Rewatch after a year, then boomeranged back three months later after realizing how much it was helping me grow.

How I work day-to-day

People often assume my skillset comes from AI. I've been asked to help others work the way I do, and the assumption is usually that I've figured out some AI trick. The reality is less exciting: I was a developer and  a designer before AI was part of the picture. People often have a hard time understanding one person does both, but I do.

My daily setup is two monitors. One runs my code editor (Cursor or VS Code), the other runs a live browser preview of whatever I'm building. When I make a change in code, I see it render in real time on the other screen. This tight feedback loop is how I design—adjusting spacing, color, layout, and animation directly in the medium where it'll live.

What makes this fast isn't AI. It's familiarity with code. I know what CSS property to reach for, how to structure a layout, where a bug is likely hiding. When I do use AI, that familiarity is what makes it useful—I know what to ask for, I can evaluate whether the output is correct, and I can course-correct quickly when it's not. Without that foundation, AI is just a faster way to generate code you can't assess.

Why code makes AI better

This might be the most important point in this entire page: Learning code has made me dramatically better at using AI (and it comes rather naturally).

The most capable AI tools today are code-native. Claude Code runs in a terminal. Cursor is a code editor. MCP servers, agentic workflows, automation scripts—all of these live in code. The interface is the code. If you can't navigate that environment, you're locked out of the most powerful tools available.

This is why high-level engineers are utilizing AI in the most advanced and meaningful ways right now. It's not because they're smarter—it's because the tools were built for their environment. Code literacy gives you access to the full surface area of what AI can do, not just the chat window.

The good news: you don't need to become an engineer. You need enough familiarity to work with code confidently—to read it, prompt for it, and know when something's off. That's exactly what this course is designed to build.