The blank canvas and the empty file

One day I was just sitting there, focused, doing my thing. Then, boom: a message from product asking for metrics. Errors from a broken pipeline. And then more. And more.

That’s when it hit me. I wasn’t thinking about the code I was writing anymore. I was thinking about latency. And OKRs.

The fun part of coding had quietly disappeared. It had turned into a robotic loop: plan, estimate, build, deliver, measure, repeat.

If this ever happened to you, here’s what I’d say: pause. Step back. Breathe. Coding isn’t only numbers and charts. (A product manager might come for me after this one, but hear me out.) What if we took a moment to look for beauty, not in a landscape, but in the code itself? Let’s be honest, most of us look at more lines of code than trees on any given day.

When inspiration failed me at work, I went looking for it elsewhere. I found it in art.

is there art in code?

You might be thinking: what is she talking about? Fair. I’m no art expert.

But we’ve all met art somewhere. Drawing in kindergarten, singing a song, wandering through a museum. That shared experience is exactly what I want to build on. So in this series we’re going to build an imaginary art gallery app together, and borrow from painters at every step.

First, we need inspiration.

Michelangelo’s components

The Creation of Adam: one complete scene among many on the Sistine Chapel ceiling. Michelangelo, c. 1512.

The Sistine Chapel ceiling is a masterpiece, full of movement and emotion. But what inspires me most isn’t any single figure. It’s the composition.

It isn’t one giant painting. It’s a collection of scenes, almost like components: the Creation of Adam, the Flood, the Temptation. Each one is a complete moment with its own emotion, framing and characters. And yet they live together in harmony. There’s rhythm. There’s flow. Nothing is randomly placed.

And it all started from an empty ceiling. Michelangelo decided on the components, how to build each one, where to place it and what role it would play in the bigger story.

what is my code made of?

So that’s my first step too. Before writing anything, I ask: what is this app made of?

For an art gallery app, the core components are fairly clear: artists, artworks, and the movements they belong to. Everything ties back to a gallery, and users interact with all of it, whether that’s browsing, booking a museum tour, or sharing a collection.

class Artist < ApplicationRecord
  has_many :artworks
  belongs_to :movement, optional: true
end

class Artwork < ApplicationRecord
  belongs_to :artist
  belongs_to :movement
  belongs_to :gallery
end

class Movement < ApplicationRecord
  has_many :artworks
  has_many :artists
end

class Gallery < ApplicationRecord
  has_many :artworks
  has_many :tours
end

Each model is complete on its own, like a single scene on the ceiling. Together, they tell the bigger story.

sketch first, paint later

No painting starts with the final brushstroke. It starts with a sketch: rough lines, a plan for the composition, a sense of how the elements will interact. Then comes the long part. Iterating, refining, adjusting, stepping back, adjusting again.

That’s the iterative process, and you already know it from programming. Our sketch is pseudocode: what goes in, what should come out, and how the pieces talk to each other.

• Users can view artworks, read about their artists, and explore the movements they belong to.
• Users can book a museum tour to see a specific painting.
• And much more, later.

Then, like a painter, we refine. We rename things. We pull out cleaner abstractions. We rework logic until it reads well. Brushstrokes or refactors, iteration is how a raw idea turns into something that feels finished.

In the next entry, we’ll follow the rules painters follow, and see what Vermeer can teach us about a recommendation service.