There’s a moment when you’re building something complex—whether it’s a piece of software or a piece of dance—when everything is a chaotic mess. The transitions are clunky, the logic is broken, and the whole thing just feels… wrong.
As a choreographer, my process for fixing this is to get a group of dancers in a room and start asking questions. "What's the core idea here? What's the energetic pathway? Where is the flow breaking?" We improvise, we iterate, and we physically feel our way to a solution.
As a programmer, my process is exactly the same. The only difference is that my "dancers" are functions and my "studio" is a code editor.
This isn't just a cute metaphor. It's the most powerful mental model I have. I've come to believe that programming and choreography are the same discipline with different syntax. Both are the art of composing discrete elements into a coherent, expressive sequence over time. And thinking like a choreographer can make you a dramatically better programmer.
Your Functions are Dancers
Let's strip this down to its essence. What is a function in programming? It's a self-contained unit of action, a "movement phrase." It has a clear beginning and end, it takes an input, and it produces an output.
- A choreographer creates a phrase: a turn, a leap, a fall.
- A programmer writes a function:
parseData(),animateElement(),calculateTotal().
The art is not in creating the individual movements, but in how you compose them. A great choreographer doesn't just string together cool moves. They build a system. They think about:
- Rhythm and Timing: A movement performed quickly feels different than the same movement performed slowly. In code, this is the world of
async/await,setTimeout, and animation easing curves. The when is as important as the what. Is your code a frantic series of staccato actions, or does it have a graceful, intentional rhythm? - Spatial Relationships: A choreographer is obsessed with space. Where are the dancers in relation to each other? What pathways do they carve through the stage? In code, this is your architecture. How do your components sit in relation to each other? Is your data flowing in clean, predictable pathways, or is it a tangled mess?
- Negative Space: In dance, the stillness between movements is as important as the movements themselves. A pause can be the most powerful moment in a piece. In code, this is your whitespace, your clear separation of concerns. It's the "emptiness" that gives the important parts room to breathe and be understood. Cluttered code, like cluttered choreography, is confusing and ugly.
Debugging as a Rehearsal
When a dance piece isn't working, you don't just throw it away. You bring it into the studio and you "debug" it. You run the sequence, and you watch with an analytical eye. "The transition into the lift at count 5 feels clunky. Why?"
- Isolate the problem: Is it the lead-up? Is the timing of the lift itself wrong? Is the dancer's preparation incorrect?
- Try a variation: What if we add a half-beat pause before the lift? What if the approach is from a different angle?
- Iterate until it feels right: You keep running the phrase, making small adjustments, until it "clicks."
This is exactly how I debug code. I don't just stare at the error message. I "rehearse" the function. I run it with different inputs. I isolate the problematic section. I ask, "What is the 'energetic pathway' of this data? Where is the flow breaking?" The console log is my rehearsal mirror, reflecting the performance of my code.
The Power of Constraints
Some of the best choreography I've ever made came from giving myself absurd constraints. "Create a five-minute piece where no dancer is ever allowed to stand still." Or, "Choreograph a trio that can only move in straight lines."
These constraints force you out of your habitual patterns and spark a different kind of creativity.
Programming is the same. The constraint of "pure functions" in functional programming forces a beautiful clarity of thought. The constraint of a "read-only state" in React leads to more predictable and debuggable applications. The constraint of a "mobile-first" design process forces you to focus on what's truly essential.
Elegance in both code and choreography is often the beautiful solution that emerges from a tight set of constraints.
What This Means for Your Practice
You don't need to be a dancer to think like a choreographer. Here's how to apply this to your work tomorrow.
1. Choreograph Your Next Function. Before you write a line of code, sketch it out. What are the key "movement phrases" (the sub-tasks)? What is the "rhythm and flow" (the order of operations)? What is the "spatial relationship" between this function and the rest of your application?
2. Rehearse Your Code. When you're debugging, don't just read the code. Run the code. Actively "perform" it in your mind or with a debugger. Feel the flow of data. Where does it get stuck? Where does the timing feel wrong?
3. Embrace Negative Space. Look at your code. Is it dense and cluttered? Can you introduce more "stillness"—more whitespace, more clearly separated blocks of logic—to make the important parts stand out?
When I stopped seeing code as a purely logical, engineering problem and started seeing it as an expressive, compositional art form, the quality of my work transformed. My code became cleaner, my architectures more elegant, and the process of building became more joyful.
Because at the end of the day, what are we doing when we code? We're taking a set of simple instructions and composing them into something that has life, that performs, that creates an experience for a user.
That sounds a lot like choreography to me.