Why I Paint and What It Does to My Code

People find it odd that I paint. Not just as a hobby — I have a catalog of 34 digital paintings, I studied at Pratt, and illustration work takes up a meaningful portion of my time. The assumption is that art and engineering are different modes: one is intuitive and expressive, the other is rigorous and systematic.

I've found the opposite. They're the same activity wearing different clothes.

Composition is architecture

When I'm building a painting, the first decisions I make are structural: where is the focal point? How do the visual weights balance? What leads the eye through the frame? These are composition questions, and they're identical to the questions I ask when designing a system: where does the complexity live? What are the load-bearing pieces? What does a user's attention path through this product look like?

Both disciplines punish the same mistake: putting detail in before you've solved structure. I've painted myself into corners by rendering a face perfectly before the proportions were right, and I've coded myself into corners by optimizing a function before the data model made sense. The fix is always the same — step back, look at the whole thing, solve structure first.

Negative space is what you don't build

In painting, negative space — the empty areas around and between subjects — is as important as the subjects themselves. Amateur painters ignore it. The space defines the shape.

In product design and engineering, the equivalent is what you choose not to build. Every feature you add is a surface area to maintain, a complexity node in your mental model, a potential source of bugs. The most elegant systems I've worked on are defined as much by what they don't do as by what they do.

Iteration without attachment

Digital painting taught me to iterate without attachment to a given state. With layers and non-destructive editing, nothing is precious — you can try a thing, see it fail, and undo without grief. I try to bring that same relationship to code. A function I wrote yesterday isn't mine, it's just a proposal. If a better shape emerges, the old one goes.

This sounds obvious, but it's actually hard for a lot of engineers. Code written under deadline pressure accumulates authorial attachment. "I spent three days on that" becomes a reason to keep it. Painting helped me break that habit.

What I'd tell engineers

Find a visual practice. Drawing, photography, typography, even just spending time with architecture in person. Train your eye to notice hierarchy, rhythm, proportion, and contrast. These aren't soft skills — they're structural thinking with a different substrate.

The best interfaces I've seen were built by engineers who could also see. The worst were built by people who could only read specs.