From Stagehand to Software
I’m set to graduate from the Flatiron School Software Engineering program at the end of the week. My journey started back in August 2020 when I first started learning the very basics of Ruby. Seven months later and it’s pretty unbelievable what I can build with just my computer and some know-how. Programming has not come easy, the learning curve is pretty steep, especially at the beginning. Once I got the hang of the process of programming I started being able to see the parallels to the work I did pre-pandemic.
For the last 16 years I’ve held a variety of roles backstage for live entertainment. You name it and I’ve done it at least once: audio, lighting, rigging, driving, carpentry, costumes, pyrotechnics, putting out food for performing animals, underwater electrical installations. As a stagehand we have to be prepared for all sorts of situations and technical problems. We all have (and love to share) stories about a show that almost ended in disaster but was saved in the knick of time by a savvy stagehand (for instance, the time our circus ringmaster fainted backstage just seconds before his cue, and the audio monitor engineer picked up a microphone and a script and made all of his announcements for the rest of the performance).
Programming isn’t exactly like that though. I don’t have to boot up my computer and be prepared with generations of institutional knowledge ready to go in my brain. Fortunately the institutional knowledge built up by millions of programmers is largely available to us online, with just a few searches.
So here are some things that should be very familiar to any stage professional, and maybe consider adding software engineering to your kit:
Break it into smaller tasks
A lot of the work I’ve been doing as a newbie web developer has been breaking up big tasks into smaller pieces. For every event in a program that needs to execute, I have to build individual functions that take in some information and outputs either a transformation of that information, or something brand new based on the input. This is analogous to breaking up a theatre set into flats. Stage people are very good at compartmentalizing things. Say I want a website to display some similar information for many many records in a database? Well I might build a function that will render all of those pieces of data into individual boxes on a page. The function in this case acts as the construction drawing, and the browser will assemble them to our specifications. This is how I felt when I was introduced to React Components. My brain automatically started viewing them as plan drawings for a stage! Just replace the 1x4s and luan with variables and HTML tags.
Data flow
In lighting and audio systems we have a concept known as signal-flow. It’s the direction a lighting or audio signal travels from the source to the output. It’s critical for us to understand and to know how to troubleshoot errors and disruptions of that flow. Programming has the same concept.
Data flow in software is all about passing a collection of information from one function within your program to another one. It is very easy to get lost in this flow, because unlike the stage, there are no cables you can trace back to the source. Having a flowchart like we sometimes have in an audio or lighting rig is an essential part of being a good software engineer, and we’re already predisposed to it!
Rehearsals === Refactoring
There is a concept in programming called refactoring. The idea is that while you’re writing your code, you have a lot of dead-ends, commented out variables and workarounds that are not very nice to look at. Once you get your program working as designed, you go back over and see if you can cut out all of the superfluous material and get it to run in a more elegant way. Consider it this way: after weeks of building a show, script rewrites, adding/cutting scenes, and making final decisions on props and costumes it’s time to do some run-throughs to make sure everyone can hit their marks on cue. Success! Great run-through. Now let’s clear the space of all of that old stuff, and forget all of the cues that have been cut. By opening night, backstage is going to be running like a well oiled machine (or a well-refactored program)
Front of House and Backstage / Frontend and Backend
In web development the frontend is where the user interacts with your application, and the backend is where the content and the mechanisms to deliver that content to the user is held. In our world, the same thing is true of the backstage and the front of house. FoH is is the pretty facade that hides the true chaos and complexity that allows the show to function. It matters less how things look under the hood, as long as performance is consistent and predictable. It goes beyond hiding the mechanics too. We are constantly considering how the audience experiences our work. From sightlines, to audio levels and intensity of the light. These things all come into play with software as well.
One last thing to take into consideration: a lot of us already know programming concepts because we already use computers to automate tasks. When I was a green electrician on the road I got a crash course in programming and operating moving light programs. Eventually I moved onto programming pyrotechnic firing systems, and then onto automated stage elevators and turntables. Sure they’re not quite the same as writing database queries or rendering data to a webpage, but it’s not hard to make the leap.
Who knows what our industry is going to look like in the next few years. I decided to learn programming because it was an obvious augmentation of the skills that we already have. There are a lot of us out there right now thinking about our next moves, and I think that software engineering should be at the top of that list.
