Creative Level Work vs. Execution Level Work #
Let us identify different ways working, which might also call “styles of problem solving”, “types of work”, or “methods of creative engagement”.
To start with an example, consider driving. When we all started learning how to drive, we had to think about every little mechanical action we took. Where do my hands go on the wheel? How hard do I press on the break? Is the car between the lines? Am I lined up with the parking space? All of these are vert specific parts of driving, and they demanded some amount of focus. Let’s call this kind of stuff “execution-level”.
If you are really focused on this, as novice drivers are, then it becomes very easy to accidentally lose track of the big-picture navigational tasks. Beginner drivers miss their highway exits more often than experienced drivers.
In this example we would call the big picture stuff “navigation”, and the mechanical stuff “operation”.
In creative software we also have “navigation” level tasks and “execution” level tasks, and they both require focus from us in order to work. Let’s call the navigation “Creative Level” work instead.
This creative level work is includes things like thinking about what elements might work in the composition, trying different things out, for example. The feedback and execution loop of iterating on an idea. You need to remember what kind of changes you are looking for, and what something looked like previously to compare it with.
Creative software has a lot of execution-level things as well. Every button press or keyboard shortcut, every small set of actions like grouping and moving objects, or a specific memorized sequence of operations.
While you are using software, identify times where you focused on the creative level, and on the execution level, and try not to focus on both at the same time.
Avoid attempting to focus on execution-level and creative-level tasks at the same time.
That’s the big takeaway from this essay.
This means, when learning how to do something, where you really need to focus on your button-clicks, the technical process; you should try working in a sandbox. Learn operation/execution in a free experimentation area. This way you can freely dive into that execution-level work and practice it, without having to worry about the larger project, or if it’s moving you towards your goals.
Then, when doing the creative-level things, try to stick to the execution stuff you are confident you know how to do. When you get an idea that you don’t know how to do, make note of it. Try not to interrupt your creative-level task to immediately go research and explore that, unless it’s truly blocking you. In which case, acknowledge that this is an interruption. Then completely switch your focus: make a note of where you are, research/practice fully and appropriately, and then switch back to your process. Don’t try to multitask.
In 3D software, I often work with multiple software windows open, one just a playground that I won’t even save. By the time I reach the end of a Unity project, I have to go delete a good handful of “testingScene” and “mechanicTest” scene files. It’s rare to reach the end of an audio composition without a couple tracks that are muted and will stay that way, which I can probably safely delete by now.
A big problem that students have is being forced into working on both learning how to do something, and deciding what to do at the same time. There are some nasty feedback loops where their ideas are constrained by their perceived abilities. It makes time management really hard!
The solution? First, I don’t have any magic bullets here. You need to practice. Focused practice, where you work on a specific technique, or specific type of creative prompt. Next, of course, is to produce a large body of work. Make lots of little things, and get experience with a wide variety of techniques.
That advice is annoying, so I have some more pragmatic advice too.
The Pragmatic Advice #
Give yourself time to research #
Learn in a learning phase, then apply it. The extreme version, which I recommend, is to do projects where you go as slow as possible. and you don’t care about the outcome. Just research the execution level of every little thing as you come across it. Don’t do every project like this. Occasionally, just dive into the tool for the sake of learning a tool.
Less extreme versions of this approach are good too, depending on your timelines. Give yourself the time to engage in a way focused on your understanding, not your outcome.
Sketchbook #
Artists, painters, and photographers all know the importance of keeping a sketchbook, be it literally or proverbially.
But programmers? They somehow never got the memo. Let me tell you now: Not everything you create needs to be finished. Not everything you create needs to be usable. You need to engage with your workflows in order to develop them. You need to isolate the part of your workflows you are weak at, and practice those.
Doing every project to completion is not an efficient way to learn. It’s the least efficient way to learn.
If a guitarist is stuck on a certain type of chord progression, they don’t practice the whole song over and over again start to finish. Yeah, sounds obvious in this metaphor. So keep a sketchbook, focus on things you are bad at, and just mess around.
The simple mantra holds true: “You get good at what you do”
To do that, you need the freedom to work in an environment where not everything you create needs to be published, and not everything you do will end up being, say, graded. Free from judgement, or quality bars the thing needs to pass. It’s a lot of pressure!
In an academic environment, it will take work to create this environment for yourself. It’s hard to work on ungraded practice while graded deadlines loom. I recommend creating consistent scheduled practice time. Setting aside time consistently makes it easier to schedule your other tasks around it. Think of a musicians who have their regular practice hours. They know they need it to improve and stay sharp, and you do too.
Reference and Objectives #
When you are in a piece of software, and tied up on execution level stuff, it really helps to have a clear objective. It free’s you from having to do creative/iterative things.
Instead - plan out ahead of time what you will try to make. Sketch out your thing on a piece of paper, then scan it into your painting or 3D modeling software, or whatever parallel is appropriate. Open up lots and lots of reference images/sound/whatever, so when you have a clear objective to reference. “I want this to look/sound like that”.
Basically, you are bypassing the part of the artistic process where you have to have a highly developed mental model of what you are creating. Developing and working on creating mental model is the creative-level things. Let’s put it aside for the time-being.
Post-it notes are the best. I’ll sketch a little 3D model with almost no detail on a post-it note, and stick it to my monitor. It keeps you focused and prevents you from iterating on creative things in random directions. (That sudden inspiration is cool and good, but do you really have time right now?).
I’ll also draw a little flow chart of my code system. In photography, I keep track of a checklist of what looks (images) I will need to deliver when editing a full session. Keep your goals in mind. It will help you prioritize.
Take Notes As You Work #
I want you to think like a coach, analyzing their players playing, and writing little notes on their clipboard. What elements should the players focus on during practice?
Back when I played youth ice hockey, our coach dedicated a third of our practices to penalty kills, which is an insane amount. But our coach knew the numbers because they took notes (whole spreadsheets, in fact) - and it turns out that we got a lot of penalties. Sure enough, we got good at penalty kills, and ended up winning more games despite the penalties. (Yes, we also needed to work on not getting caught by the ref. I mean at playing clean).
Becoming proficient in a piece of software means being able to work almost entirely in the creative space, because you aren’t really thinking about your tool (the execution level). You are thinking “Maybe this image would look better desaturated. Hmm, no, maybe not.” and not “Where is the adjustment layers window again. Should I use a saturation adjustment or a black-and-white adjustment layer with low opacity. What’s the difference?”. Identify times you got taken out of the creative space, and make note of them. (You can write a note on a post-it: “Parenting things in blender, wtf”) When you have more time, go research. You will be learning exactly the things that have been slowing you down, and you will get better.
You need to be your own coach. Nobody else is doing it. Keep a piece of paper (or whatever - how I love software that lets you keep little text notes right inside them) - and just jot down something that got you stuck, or that you spent time on. Once it’s externalized (written down), you’ve freed it from your mind. You don’t need to worry about it until later, when you look over your list and go “yep yep, time to figure out the whole parent/child process”. Then do that. For example, maybe you finally just sit down to memorize the syntax of a ‘for’ loop.
Students, this is why I prioritize so much time to in-class workshops, and send you to places like this website for lectures and learning. It’s called the “flipped classroom” pedagogy, and it allows me to give you better feedback of the actual little things that are tripping you up, and hard to research. To stay on-metaphor, it lets me be a software coach.