There's a piece of code I keep returning to. It's about forty lines of Rust, and it draws Voronoi diagrams — those cellular patterns that appear in giraffe coats, dragonfly wings, and the cracks in dried mud.
I wrote it without any practical purpose. I wrote it because I found the mathematical structure beautiful and wanted to understand it from the inside. The process of writing it felt less like engineering and more like sketching — trying things, backtracking, finding a shape I liked.
I've started to think that this is an underexplored dimension of programming: code as an expressive medium, not just a functional one.
The False Divide
We've inherited a mental model that separates technical and creative work cleanly. The engineer solves problems. The artist expresses something. These are considered different activities, perhaps even different personality types.
But the history of computing doesn't support this clean divide. The early programmers at MIT's AI Lab were obsessed with elegance — not just in their algorithms, but in the feel of their systems. The Lisp hackers who defined so much of computing culture weren't indifferent to beauty; they were consumed by it.
John von Neumann reportedly judged mathematical proofs partly on aesthetic grounds. Donald Knuth titled his life's work The Art of Computer Programming. The word "elegant" appears more often in programming discussions than in most art school critiques.
What Generative Systems Revealed
The emergence of generative art over the past decade has made something visible that was always true: code produces aesthetic output, and that output can be the point.
Artists like Tyler Hobbs, whose Fidenza project became one of the most celebrated NFT collections, write algorithms that generate unique images by iterating through parameter spaces with deliberate randomness. The code is the artwork — not the images it produces, but the system that generates them.
What's striking about this work is how it collapses the distance between mathematical structure and visual beauty. A flow field algorithm doesn't try to be beautiful. The beauty emerges from the logic, the way harmony emerges from mathematical relationships in music.
"The computer is a powerful tool for the exploration of aesthetic space. We're still barely learning to use it."
Functional Programming as Aesthetics
There's a particular affinity between functional programming and this aesthetic sensibility. Functional code tends toward expressions over statements, composition over mutation, small functions that do one thing well. These are constraints, but they're generative constraints — the kind that sharpen attention and produce unexpected solutions.
I notice something similar in the difference between writing a complex nested loop and writing the same logic as a series of composed functions. The latter often feels more right — not just more readable, but more honest about what the computation actually is.
This is an aesthetic judgment, and I've stopped apologizing for making it.
Writing Code Worth Reading
One underappreciated dimension of programming aesthetics is code as prose. The best code I've read has a voice — a consistent sensibility about how to name things, structure ideas, and signal intent. Reading it feels like reading a careful essay: you sense the mind behind it, not just the output.
This is different from "clean code" in the conventional sense. Clean code is about hygiene — reducing noise, following conventions, making the next programmer's life easier. Code with voice goes further: it has an argument. It communicates something about how the author understood the problem, and what they valued in solving it.
Writing code this way takes longer. The returns are harder to measure. But I've found that code written with this kind of attention tends to age better — it stays honest about its own structure longer before the compromises accumulate.
The Practice
If any of this resonates, I'd suggest a simple experiment: write something with no practical purpose. A visualization, a simulation, a small generator. Choose a system you find intrinsically interesting — cellular automata, fractals, physical simulations, anything.
Then write the code as if it's a piece of writing. Revise it. Let the structure change as your understanding of the problem deepens. Pay attention to what it feels like to read it back.
You'll likely produce nothing publishable. But you might discover something about how you think — and how you want to think.
That seems worth the time.