The Debugging Mindset

The Debugging Mindset

The unexpected parallels between dance, debugging, and creative problem-solving.

There’s a moment every developer knows too well—when nothing works, the console screams red, and your brain feels like it’s buffering. I used to think that was failure. Now I see it differently. Debugging isn’t punishment—it’s perspective.

From overwhelm to curiosity

I first discovered coding during the COVID pandemic and, like many beginners, I found it hard—so hard that I quit, came back, and quit again. I’d follow YouTube tutorials line by line hoping it would eventually “click.” Inevitably, I’d finish a component or script and get hit with a wall of errors.

My first thought was always: I can’t do this. I’m not smart enough. Over time, the errors stayed—but my mindset shifted.

I realised that if I wanted to grow as a developer, I had to embrace the challenge of problem-solving. Blindly copying wasn’t helping. I didn’t need to understand every single line from day one, but I did need to know what the code was trying to do and why it existed in the bigger picture.

Borrowing from dance

As I went deeper into development, I kept drawing parallels to something I know well: dance. Rehearsal and debugging share the same rhythm—observe, adjust, repeat. The fix isn’t just in the steps (or the code). It’s in the mindset.

I even debated once whether coding is creative or purely logical. For a long time I leaned “logical.” Now I think the best work happens where creativity and logic meet.

A tiny history that proves it

Look at how sorting algorithms evolved:

  • Bubble/Insertion Sort: the simple, “manual” approach—step through elements and swap as needed. It’s like rehearsing every step until it’s clean.
  • Merge Sort: the creative leap—divide the list, solve smaller problems, then merge. Don’t fight the whole thing at once.
  • Quick Sort: choose a pivot to organise the rest—one clever decision shapes the entire flow.

Each leap wasn’t just more logic—it was a new way of thinking about the same problem.

A portrait of Stephen Vincent merging two worlds — coding and dance — representing creativity and logic working in sync.

Three rules I use when I’m stuck

  1. Pause before you panic. Breathe. Read the error like feedback, not failure.
  2. Break it down. Isolate the smallest piece that fails. Comment out, log values, test a tiny path.
  3. Stay playful. Treat problems like puzzles. Try a different angle. Small experiments beat big rewrites.

Build like choreography

When I’m learning a new concept or tool, I approach it like choreography:

  • Outline the vision. What should this actually do?
  • Chunk it. Break the build into tiny, testable sections.
  • Draft, then refine. Get a rough version working before polishing.

That mix—clarity of vision + willingness to iterate—is where the debugging mindset really shines.

The beauty of testing

For a long time, I thought testing was unnecessary — extra code that no one ever sees. Why spend hours writing scripts that don’t even make the app look better?

But then I started thinking about how we train in dance. Before performing a routine on stage, you drill the fundamentals: posture, rhythm, weight transfer, timing. We have systems and processes that make every movement consistent and efficient.

That is testing — just expressed through movement instead of code.

Unit tests are like technique drills. Integration tests are like running the full choreography with your partner to make sure everything connects.

And when something goes wrong on stage, it’s the hours of testing (rehearsal) that help you recover quickly.

Once I made that connection, testing stopped feeling like a chore. It became part of the art — a structured way to build confidence in what I’d created.

Testing, like rehearsal, is where creativity meets discipline. It’s not there to slow you down — it’s there to make sure what you build can dance under pressure.

Try this next time you hit a red screen

Before you Google the full error, write one sentence: “What was I expecting to happen?”

Then test the smallest possible version of that expectation. If it works, expand. If it doesn’t, shrink again. You’ll find the bug faster—and you’ll train yourself to stay calm in the chaos.


If this resonated with you, I’d love to hear your thoughts — what’s your approach to debugging or staying creative when things break?

Drop a comment below or share this with someone who’d appreciate it.

And if you enjoyed it, subscribe to Debugging Life — my weekly newsletter on creativity, tech, and the messy process of learning.

Til next time!

Stephen

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to my newsletter

I’d love to keep you updated with what I’m building, learning, and exploring along the way.

Subscribe to my newsletter, Debugging Life — a behind-the-scenes look at my journey through creativity and technology. I share lessons from projects I’m working on, tools I’m experimenting with, and reflections on the process of becoming a better creator.