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

This one might seem a little obvious but you might not realize that working on a computer all day during your career in post makes you well suited for software development. After years of working in post you learn what works for you in terms of when to take breaks, organizing your workstation for comfort and efficiency, and figuring out how to continue concentrating after staring at a screen all day. This all takes practice and will certainly pay off when learning to code.

Working with a Team and Having a Specialty

Most jobs in post production involve working on a team. There are editors, colorists, sound mixers, conform artists, vfx artists etc. who all are involved in the production of one final project. This is true for software engineering as well. There are front end developers and backend developers, project leads, database administrators, managers etc. who all play an important role in getting an app to market.

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”

In my career I’ve typically worked with a team but have also done many freelance projects where I planned, shot, and edited the final project working completely by myself for a client. This is also a typical path that can be followed in software development and these types of people are usually called “full stack developers” meaning they work on the back-end and front-end of a piece of software.

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

A great plan is key to the success of any project, and there are definitely some overlaps in how software developers and video professionals plan their work. One of the first concepts you will encounter when learning to code is called “pseudocoding.” Pseudocoding is the process of writing down the steps you want your code to take in a way that’s easy to understand, and isn’t necessarily written with a programming language. This pseudocode is then used as a starting point for writing the actual code and creating a minimum viable product, or MVP.

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

Organization is key to the success of any video or software project. In post production you need to make sure to keep your footage properly organized at the filesystem level as well as organized within your bins and timelines. You label your shots according to scene and take numbers, add comments for each shot, and make sure there is a logical structure to your timelines.

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

If you’re a post production professional who would like to start learning how to code I recommend working on practical projects that are related to post. For example next time you need to encode a video to H.264 try to use an FFmpeg script instead of a GUI based tool, try your hand at some After Effects expressions like Wiggle() to simulate a shaking camera, or rename files using Python instead of using Automator.

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