The problems of speed

Speed is a valued skill in programming. Working faster can often correlate to being more cost effective, shorter development timelines, and more iterations. These are all good things but they lead to developers becoming tired and trying to take shortcuts to save time and energy.

Shortcuts are a good thing in development. Shortcuts have lead to new programming languages and techniques that have become standard practice over time. Object oriented programming is a good example of a technique that might have been seen as a shortcut by some but ended up being a revolutionary programming technique. But the devil is in the details of the shortcut. Some shortcuts involve us thinking less and clicking more. We’ve all done shortcuts to avoid complexity but then were left with systems that took a long time to update or require an hour of copying and pasting data and values around to set it up correctly.

We just recently finished a gig where I got caught in this trap. So how can we approach shortcuts in a positive way?

I try to think to myself:

“Have lazy fingers and not a lazy mind”

A game of abstraction

Being lazy means doing less monotonous work. A lazy mind will lead you make solutions that don’t require much thinking and feel easier at first, but can lead to solutions that involve a lot of monotonous upkeep.

An example of this is needing to having 2 shows that are similar but maybe have different file paths. The lazy mind solution would involve copying and pasting the existing show and changing file paths in the new copy of the show. Sounds lazy, right? But what happens once you realize you need 20 different shows with different file paths. If you continue on the lazy mind path, you’ll have 20 different shows that will need to be maintained as assets are changed and updated. That’s why it is important to focus on having lazy fingers instead. The lazy finger solution would be to make 1 script that could then update all the paths in the single show you have based on data written in a table or file.

The lazy finger solution looked for a high-level way to group all the shows functionality together. Abstraction is the key to being lazy the right way. You want to find high-level feature designs that can cover as many small level details as possible. This is the rationale behind moving towards object-oriented programming. Object-oriented programming is a method of programming where you try to make abstract templates of data and functionality that can then be passed down and specialized as needed. Abstraction will make updating software easier, as you need to update software in less places.

How would that work?

Another example would be a system with different modes that have related content. In TouchDesigner, you might make an external component with a large movie, a bunch of small movies, and some images that are all related and should play at the same time. Creating multiple shows would be as much work as it is to copy and paste the external component, update any asset paths, and then save it. Not too shabby. This strategy can work just fine but you might fall prey to a situation where you have 10 or 20+ shows that might need some form of iteration or content update. At that point, you’d have to go into every single show component and make the same changes over and over again.

One abstraction solution could be to create some re-usable components that are referenced inside of each of the show components. That way you can just make changes in one place and have them propagate. Another solution would be to create the software to focus on the modes instead of the content. This would be similar to having a module for running large movies, another module for small movies, and a module for images. These modes would all be scripted together to dynamically load in the required content. Updates to the systems would be as simple as updating the loading scripts or the mode modules in one place.

The impending doom of deadlines

Talk is cheap when it comes to working on-site and under the gun. Things are coming at you from all directions and decisions are fast and loose. Clients are unsure of their wants and needs and agencies are usually under fire from a lot of angles so things need to happen fast and iterations need to be rapid.

My 3 tips that I try to think about:

1. Have a coding filter. Just like you do with your words, think before you speak. Wait 30 seconds before you start programming anything, even if it’s easy. Give yourself a moment to think it through, think about possible traps that could exist in the future.
2. Bounce your idea off someone else. Whether it’s another member of the team with you, or you phone a friend.
3. Think about the last time you did something similar and if you had any mental notes that you had made. Often times, we tend to forget our own experiences in the heat of the moment and can repeat similar mistakes.

My hope is that these recommendations can help keep you light on your feet in high-stress situations and can keep your code easy to manage over the long term.