Confusion vs. Complexity.

Learn the difference between confusion and complexity.

Complexity is a status of a thing. Things can be complex. Confusion is a mental state. It is inside of you, a reflection of your relationship to the software.

When you are confused, stop and figure out what it is that is confusing you. “Why did this person in this video tutorial choose to do it this way?”

You want your mental model of what is happening match the reality of what is happening. When one is confused, it can be because the systems that they are interacting with have more complexity than their mental model supports.

Unfortunately, it is hard to develop complex mental models to match complex software systems, because we also want to, you know, use the software.

When you are faced with some setting you don’t understand, something confusing, you may feel tempted to take a shortcut that bypasses learning about the thing. Perhaps you just rely on defaults, or solve the problem in some roundabout way you already know how to do, or blindly follow what some website like this one says, or whatever “hand-wave-for-now” thing in order to do what you need to do. A pragmatic approach that you cannot be judged for taking, particularly when faced with deadlines. I implore you: At least make a note of the part where your understanding (mental model) didn’t match the software.

To reduce confusion, we can either make our mental model more complex, to match the complexity of the system we are working with, or we can make the software more simple, to match our mental model. Both approaches are perfectly valid, but learning something tends to be way easier than switching to simpler systems or taking shortcuts. No, I know, there is a bit of valid criticism you can make about this advice: “You’re only saying that because you’re a professor and it’s your job to develop students mental models of complicated things”. To which I say: “well yeah”. But ALSO it’s true. Learning is the easy way out! I promise.

Here would be a good place to insert some quote about teaching people to fish, and how long they get fed for.

To be fair, making software simple is often an excellent approach! In practice, it can mean closing or hiding windows/panels/tools that we do not need. Only presenting ourselves with an interface that does things we want it to do. I do this all the time, especially in Photoshop. I edit images, I don’t do digital painting. So digital painting tools? Get outta here! I don’t need to learn about you. I did the same in blender and Cinema4D to shoo away rigging and animation tools. If all I am doing is hard-surface 3D modeling, then… shoo!, unnecessary complexity! “Lets hide that feature-set I don’t care about” is a valid approach and will help you make your world easier to work with.

There are troubles with simplifying software to match your mental model. One is that the software is complex for a reason, and usually that reason is that it is doing complex things. Editing audio, programming, or making 3D models is hard! It’s a complicated thing we are doing, and our tools deserve complexity to handle it. You can only simplify it so much before you end up removing features that you need, or you end up asking the software to make assumptions, and computers are terrible at making assumptions.

Other times, simplifying software is impossible. We end up simplifying our relationship to the software. We memorize or follow a sequence of actions without really knowing what they do, but trusting the output from these actions.

Other times, efforts at simplifying tools means trying to apply a known mental model to an unknown tool. “I’ll just do it the same way as this other thing”. And now you have GIMP users using destructive workflows in Photoshop, or my Aunt sending me images by putting them in a word document and emailing it. It… works? Sort of? …What are we trying to do here anyway?

Remember that episode of Spongebob Squarepants, where Spongebob shows Squidward how to draw a circle: ‘First I draw a head, then I erase some of the more detailed features.’ That’s what watching students who attempt to apply a known workflow to a new toolset can be like. “I mean, sure, you got there in the end, but there are easier ways”. Such crutches are necessary to get you started, but end up getting in your way, and they are phenomenally inflexible: You can’t take this approach and transfer it again to do something else in the software, and you probably haven’t really learned much.

As you learn creative software, you should prioritize expanding your understanding of tools. Not just how to use them, but why they exist, what they do. That means reading the manual, and not just following guides. (Here I would like to make note of the semantic difference between ‘guide’ and ’tutorial’). When you learn, if you only keep following or memorizing different sets of steps to take, you won’t be developing your mental model, and you will learn the software much slower, and have more trouble with it. Your relationship to it will stay confusing.

So back up and get your fundamentals under control, okay? Most of your pain comes from trying to avoid having to expand a mental model. But you aren’t being lazy, you are being pragmatic - you just are trying to look up this one specific thing, you don’t have time to learn about video encoding formats or whatever. So how do we balance learning tools vs. actually-getting-things-done? One way is to make sure we give ourselves time to develop mental models when we aren’t under a deadline or have an immediate goal. So make a note of what you should look up later when you do have time, and be sure to engage in sketches/projects/research that are for the sole purpose of following up on those notes.

Do these slow learning projects where you read the manual on every tool you open, and let yourself dive deep. Pick up knowledge you might never use, and be happy about it. You can’t only do pragmatic just-get-it-done projects. Especially students, because doing that defeats the whole point of you learning these new tools. So work early! You can’t do educational and iterative work right before a deadline, because the deadline forces pragmatism!

Professorial grumbling: when you only work right before deadlines, it’s like your whole plan is to just make life as hard for yourself as possible. Please, value time management more.