This isn’t my normal content, it’s a discussion post rather than a tutorial.  This last week I was teaching an Eos class to a mixed group of High School students for four days.  Some had some experience in lighting, while others had none.  Typically, when you go to attend a console class, you need to bring a sense of what it is to be a programmer with you for the instruction to make sense.  The context of a situation may be provided (or not, depending on which class you’re in) and it’s up to you to recognize the value of a concept to your own work flow.  In this class, that wasn’t really possible.

The beginning concepts in the four day class are the clearest and have the most context.  Want to control lights?  You need to patch them.  Want to tell the lights to do something?  Select them.  Is there a better way to select them?  Introduce Groups.  But as the materials go on, they get increasingly abstract and I was worried the students would shut down or give up.  So I went rogue.

The teacher of the students at the beginning gave me permission to go off the written materials, and I started with controlling a couple lights- a Colorsource and a Lonestar- with a DMXcat to give them background on profiles, additive and subtractive color, DMX being an 8 bit protocol, addressing, etc.  I had them look up the product manuals and profile DMX charts to be involved.  

So later in the week when we finished Levels 1 and 2 and I was sensing the class had all the abstraction it could stand, I again asked the teacher if it was ok for me to go off book and maybe start teaching programming in the context of design projects.  She agreed, and I opened a discussion with the students about maybe lighting the opening number from a musical.  Fortunately, the class was responsive to musicals (as a life-long fan of musicals, not a lot of tech people like musicals).  So we did the opening number to Legally Blonde.  I described the action for the students- where the story begins and where we get to through the beginning of the story.  They worked as teams per console to co-design and program.  Some interesting things happened.

• Everyone was a designer.  Though they often had questions about building out lighting ideas, no one shut down and said “I don’t know how to design”.  They ALL had a vision in their heads that they wanted to put on stage.  It was really fun getting to see everyone lighting the same material and at the end of each design project, we all went around and examined everyone else’s work and discussed things we noticed and responded to.
• No one got super hung up on the staging.  I gave them some staging suggestions once in a while to minimize the semantics so they could get to making design decisions.  But I also told them they could ignore me.  They made up their own staging quite well.
• Students did ask many times how to do something I had already taught them, but this time THEY WANTED THE ANSWER because they needed it to fulfill their vision.  I kinda think they will remember far longer than the things I taught them while they were passively listening.  Watching them work makes me hope this is true.  Once THEY wanted a technique and I told them, I almost never had to tell them a second time.  On more complex procedural things like effects- yes I answered the same thing many times.  But I think that’s pretty normal since effects frequently take a while to become clear to new programmers.  
• I had the opportunity to teach a few of the concepts from Level 3 and 4 because their designs needed them.
• Discussions between the students were animated and focussed.  They seemed to be really engaged.

In total, I believe we lit five songs from musicals and ended with busking a pop song chosen per team.  I should have dropped one of the musical numbers in favor of giving more time to the busking since the technique is very different from a traditional single cue stack work flow.  

Context is valuable stuff.  If you don’t have any context for programming how much of a console class can you take in?  Make no mistake- knowing the console is only a small part of being a programmer.  There is much, much more. And since there are few if any books or videos dedicated to teaching you all that assumed knowledge- experience is currently the only way to learn the job.  Observing or being mentored.  That is a bit of a weakness in our existing systems of education in my opinion.  I was lucky that everyone engaged in the ideas of design, which made them have more context to learn programming.

In the past when I teach IATSE brethren, I’ve done a similar concept of teaching the materials in context of a job.  I welcome the students and throw an instrument schedule, light plot and channel hookup on their desks.  I tell them they are on a corporate gig, doors are at 3pm.  The paperwork I gave them contains lies and errors.  Then I tell them they need to ask me questions or I won’t tell them anything.  I sit in silence as they collectively try to decide if I’m for real or not.  My extended silence tells them I am.  The class then all looks at each other to try to remember a key word that will help them.  Someone finally gets bold enough to say “Patch?” and I lead them through patching the show before making them ask me the next question.  In my informal testing, this method is far more successful than walking them passively through a bunch of functions that they themselves are expected to know the value of.  This results in a longer retention.

Ah, retention.  Forgive me for repeating myself, but learning to program is like learning an instrument or setting a fitness goal.  Regular practice is what makes it possible.  There is no way to learn to program in four days.  It takes months and years of constant practice.

If you’ve taught- what techniques have you used to overcome the context issue?  If you’ve not taught, how did you learn all of the parts of programming that isn’t just how the console works?  Would love to hear your experiences in the comments.

***

Mark LaPierre is a programmer in film and television based out of Albuquerque.  He grew up in live entertainment and has been a designer/programmer for musicals, concert dance, live music, circus and corporate.  Mark is a proud member of IATSE and an ETC Eos trainer.  If you enjoy his content, please consider commenting on his posts on the website to appease the Algorithm.