How I Taught Myself To Code In Coffee Shops On Tour

When I was touring with bands, doing lighting, stage design, and tour managing, the days had a rhythm. Wake up. Drive to the next city. Find the venue. Load in. Soundcheck. Show. Load out. Sleep. Repeat. But between waking up and getting to the venue, there were a few hours of downtime, and I started spending them in coffee shops teaching myself how to write code.

That decision, made without any grand plan, turned out to be one of the most consequential things I have ever done. The software skills I built in those coffee shops are the foundation of the interactive projection system at The Table 30A. Every time a guest waves a hand over the table and watches the projected visuals respond, that interaction runs on code I wrote, and the ability to write it started in cities I barely remember, hunched over a laptop between a cortado and a set of headphones.

Why I Wanted to Code

The motivation was not abstract. I had a specific problem I wanted to solve.

On stage, there were multiple computer systems running simultaneously. The lighting console, the video playback system, the audio rig. Each one did its job well, but they did not talk to each other. If I wanted a lighting change to trigger a video effect, or a bass drop to shift the color palette of the entire stage, I had to program each system independently and hope the timing lined up.

I wanted to make those computers talk to each other. If I could write software that sat between the systems and translated messages between them, I could build effects that were more elaborate, more responsive, and more connected to the live performance than anything a single system could produce.

That was the goal. Make the computers on stage communicate so that the show could be greater than the sum of its parts. The irony is that this exact principle, connecting disparate systems into a unified experience, is what I do at The Table 30A today. The projection system, the tracking, the sound design, and the visual engine all need to work as one. The software that connects them grew directly out of what I started learning in those coffee shops.

How I Learned

I did not have formal training. I did not take an online course. I bought books and read documentation and wrote bad code until it got less bad.

The early work was in protocols. I needed to understand how the lighting consoles communicated so I could intercept and extend those signals. That led to learning about network programming, data formats, and real-time systems. The real-time part was critical. Live performance does not tolerate lag. If a lighting cue is supposed to fire on the downbeat, it has to fire on the downbeat. A hundred-millisecond delay is visible and unacceptable.

That constraint, the demand for real-time responsiveness, shaped how I think about software to this day. The interactive projection at The Table 30A operates under the same constraint. When a guest moves a plate and the projected visuals respond, the response has to feel instantaneous. Any perceptible delay breaks the illusion that the table is alive. The discipline of writing real-time code for live stage performance is what prepared me to build a real-time interactive system for a dinner table.

The Coffee Shop Classroom

There is something specific about learning to code in a different city every day that I think made me a better developer. Every coffee shop was a different environment. Different noise levels. Different internet quality. Different distractions. I had to be able to focus anywhere, on anything, for whatever time I had available.

Some days I had three hours. Some days I had forty-five minutes. I learned to work in bursts, to pick up a problem where I left it the day before, and to make measurable progress in a short window. That ability to context-switch quickly and work efficiently in unpredictable environments is exactly what producing a pop-up dining show requires. Every venue is different. Every setup has its own challenges. The ability to solve problems in unfamiliar conditions was trained in those coffee shops as much as it was trained on stage.

From Stage to Table

The first programs I wrote connected lighting consoles to video systems. The programs I write now connect motion-tracking cameras to visual engines that project interactive media onto a dinner table. The scale is different. The context is completely different. But the core problem is the same: make the computers talk to each other so the experience is greater than the sum of its parts.

At The Table 30A, the tracking system reads the positions of hands, glasses, and plates on the table. That data feeds into the visual engine, which generates abstract, colorful projections that respond in real time. When guests wave their hands or pass food, the visuals change. The system is custom-built, and every component, the tracking, the rendering, the projection mapping, the interaction logic, needs to communicate seamlessly for the experience to feel alive.

I would not be able to build that system if I had not spent years in coffee shops solving simpler versions of the same problem. The road gave me a reason to learn. The coffee shops gave me the space. And the skills I built there are in every show I produce. I wrote about how those skills manifest in the Table 30A technology specifically in How Interactive Projection Works At The Table 30A.

What Coding Taught Me Beyond Code

Learning to code did more than give me a technical skill. It changed how I think about creative work.

Before I could code, I was a user of tools. I operated the lighting console. I ran the video system. I was proficient, but I was limited to what the tools could do. Once I could code, I could build my own tools. I could make things that did not exist yet. That shift, from operating tools to creating tools, is the difference between executing someone else's vision and executing your own.

The Table 30A is a format I invented. The interactive projection system is a tool I built. The way the story, the food, and the visuals come together is a process I designed. None of that would be possible if I were still limited to operating existing tools. The ability to write code gave me the freedom to imagine an experience and then build the technology to make it real.

FAQ

What programming languages do you use?

The specific languages and frameworks have evolved over the years. What has stayed constant is the focus on real-time systems, interactive media, and connecting multiple devices into a unified experience. I use whatever tools best serve the specific project.

Do you still code the projection system yourself?

Yes. The interactive projection system at The Table 30A is custom software that I wrote and continue to develop. For the second show, From Here. From Home., I reworked the entire tech stack to make the installation movable and enable interactive media on all projectors.

Could someone without a coding background create something like The Table 30A?

The coding is essential to the interactive component, but the broader experience design draws on skills that go beyond code: storytelling, collaboration, pacing, and understanding how people experience a shared meal. The coding makes the technology possible. The years of live event experience make the show work. I trace how all of these skills come together in From Echo Park Intern To Immersive Dining Creator.

How long did it take to become proficient?

Years. I was learning in coffee shops between tour stops, which meant progress was incremental. But each small step solved a real problem, which kept me motivated. By the time I transitioned to working in creative studios, my coding skills were strong enough to be professionally useful.

Is the Table 30A software available for others to use?

No. The system is purpose-built for The Table 30A and is part of what makes the experience unique. I wrote more about the technology in How We Rebuilt The Tech Between Our First And Second Show.