Learning a Craft

11 February, 2019

I remember when I first learned about computer programming, around 2008 or 2009. I wanted to make games, and asked a search engine. Apparently computer graphics was way too hard, so I decided I wanted to create browser-based static HTML games and text-based roguelikes. Having learned that PHP and MySQL exist, I sat down and brainstormed a setting, classes and roles for characters, and all the other things that come with fantasy RPGs.

Soon after, I realised I wasn’t capable of building any of it.

At the time, even the simplest programs were incredibly confusing, and the complexity of a browser game was far beyond me. I’m lucky that I didn’t give up on programming after realising I couldn’t build any of my cool ideas. For me, just being able to make computers do things was enthralling, and my learning became self-propelled — games be damned.

Contrast this with how I’ve recently approached another activity that I’m interested in, but very bad at: creative writing. For a while now I’ve wanted to learn how to tell stories, and this has been my process so far:

“I want to write stuff.”

“Not just any old stuff, but cool stuff; interesting stuff.”

“But I don’t have any cool ideas!”

“Guess I won’t write about anything then.”

In other words: I’ve learned nothing, because I haven’t done anything. I’ve been paralysed by this desire to only make ‘interesting’ things. It’s easy to imagine that other people have been stuck in similar situations with programming: someone wants to learn to code, but doesn’t know what to build, or only wants to work on seriously cool and ground-breaking projects. And I’m sure it’s not only programming; it seems there’s a common set of problems facing people who take up a craft. To address this, I’m going to think of advice that I would give to beginner programmers and generalise it.

Drop your standards and shelve your ideas

At the start of the learning process, you have barely any ability. This means that by most standards, you will produce a lot of terrible, unskilled work. But that’s okay, because at this stage each piece of work is a step toward improvement. Each thing you make exists so that you can figure out how to make the next one better. Your standards, or taste, can still point you in directions for improvement, but your mistakes and shortcomings are not bad things.

If you have any grand designs, put them on hold. Chances are you don’t have the ability to see them through right now. Sometimes lofty ideas can help you figure out which areas to study – if you dream of making a first person shooter then you should definitely learn about 3D graphics. In general, though, I think it will help to put the big ideas aside until you’re more skilled.

Make EVERYTHING

When I started coding, I made calculator and to-do list apps, tiny database-backed webapps and 2D space shooters and brick breakers. None of this was remotely novel; it was a challenge just to repeat what others had built before me. Even though I wasn’t building anything original, I was still creating something that I had never made before, which was a huge learning experience. Even simple programs, like a calculator, require important fundamental skills that I didn’t have. I encountered problems that had been solved countless times by others, but that didn’t diminish the value of solving them for myself.

Getting into this mindset seems especially difficult in ‘creative’ endeavours like writing, game programming, or visual art. It feels like in these areas, there’s a big emphasis on being unique, imaginative, and innovative. While this is a fine standard for experts, it’s the wrong way for beginners to approach a craft. Making shiny new stuff comes later; right now you need to re-make old stuff.

Replicating past work doesn’t mean to copy things out line for line. Copy the idea, and figure out how to fill in the details yourself. When I sat down and said “I’m going to write a brick breaking game”, I didn’t go and cut sections of code out of other similar games. I took the un-original concept, broke it into smaller components, and figured out how to make each of those bits. How do I display a ball on the screen? How do I make it move? How do I make it bounce? Each sub-problem required original thinking on my part, and it’s this original thinking that drove my improvement.

Find joy in the process

Motivation is really important for making consistent progress in a skill, but not all motivations are equally effective. I think the least sustainable motivational source (but most common for beginners) is ‘wanting to make something good’. If this is your main motivation, then you’ll be in a constant state of discouragement — every piece of work a reminder of your lack of ability. These little negatives slowly add up until you resent the activity.

A better motivational source is ‘to improve at something’. With this perspective, you feel accomplishment whenever you notice that your skills have increased, which happens often for beginners who practise regularly. But improvement-based motivation isn’t enough on its own; there are periods where you won’t notice improvement, but it’s important to practise anyway.

The most important and fundamental source of motivation comes from enjoying the activity itself. If you enjoy the craft regardless of standards of quality or ability, then it doesn’t matter how ‘bad’ your work is in the beginning, because producing it is a joy in itself. I’ve spent days and sometimes weeks stuck trying to make my code work the way I intended, but that’s all okay because it’s part of the process. At the end of the day I just like making computers do things.

I mainly wrote this for myself, to get a bit of a handle on why I find writing so difficult and how I can make it easier. I think it has helped. The next thing I write (not on here) will likely be the literary equivalent of a command-line calculator program — and that’s okay.

All this ‘advice’ may seem obvious to some, or lacking in original insight, and I’m sure other people have written about these things to greater effect than me. But that’s beside the point, isn’t it?