Making the shift from post production to software development

After many years of working in post production I recently decided to shift gears and try to break into the tech world as a software developer. I attended the Flatiron School where I learned how to build apps with technologies like Ruby on Rails, Javascript, and React, and along the way I realized that the skills I had gained in post overlapped almost exactly with software development.

So if you are a video professional looking to make the shift to software development too, I’m going to demonstrate that there are many parallels that can already make you well suited for the job.

Working on a Computer All Day

Working with a Team and Having a Specialty

If you’ve worked on a post production team you understand that you must communicate with other departments at each step of the process and you know that being an expert in one department is great but oftentimes not enough. You should have at least some knowledge of how each department operates, otherwise communication breaks down and projects can become headaches.

The “One Man Band”

If you have ever worked on a video project completely solo you know that it can be challenging at first but eventually you develop workflows to make it easier to manage. I found a lot of fulfilment during Flatiron School when working on my final project and it was a very similar feeling to working on solo video projects.

I found that having personal side projects to work on was important while working in video production, as it helped keep me creatively fulfilled. So even if at a future software engineering job you are not working solo on something, you can still create apps in your spare time to keep yourself engaged in your work. Here’s a great YouTube channel I found for some inspiration if you’re trying to become a solo full-stack developer:

Project Planning

I equate the MVP with creating a rough cut in post production. All good editors start with a rough cut, it’s not something that you will show to the client right away, but it really helps to just get something on the timeline that you can work with. Oftentimes after putting a rough cut together I will get an idea that I hadn’t previously thought of, and the same is true for pseudocoding where after seeing it written out I can get a different perspective on what the final code should look like.

After the rough cut is put together and shown to producers, directors etc. for feedback, the editor will continue to fine tune the cut and continue adding version numbers along the way. This is quite a similar process in software development where an alpha and beta version of a piece of software will be released to a select few people for testing and then a final release version is made available to the public after feedback has been incorporated.

Staying Organized

Software development projects are very similar as you break down pieces of code into separate functions that each have a logical purpose, and you make comments along the way to let others know how your code operates. There is a logical flow to well written code and it should be easy for another developer to jump in and help out when necessary. The same can be said for a well structured timeline with different color coded tracks corresponding to things like main video, overlays, dialogue, sound effects, etc.

One of the guiding principles in software development is to write what’s called DRY code. DRY stands for “Don’t Repeat Yourself” and when code doesn’t meet this standard it is sometimes referred to as WET which stands for “Write Everything Twice.” To ensure that code remains DRY developers will organize their code into reusable components.

This same concept applies in post production with nested sequences and Precomps. Take a lower third for example, you might have several layers of graphics and one layer of text that make up a lower third animation, and it needs to be used many times throughout the edit. Sure you can copy/paste those layers each time you need to use that lower third, but what happens when your client asks you to change something? You would have to find every single instance of those lower third layers and make the changes to each one, quite an inefficient process.

To solve that issue you would of course create a nested sequence for those lower third layers and copy that nested sequence each time you needed the lower third graphics, thus only having to make the change one time in the original nested sequence. This same exact principle applies to DRY code, it’s just far more efficient to write code once, wrap it into a component or module, and refer to it as needed.

Start With What You Know

Thanks for reading and let me know if you have any more tips for learning to code in the comments!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Arthur Wilton

Software Developer and Video/Post Production Professional. Recent graduate of Flatiron School.