Learn to code. Or don't.

This article is the elder sibling of my shorter Ask The Fox post on the same subject. It's bigger and more detailed.

Reasons to learn to code:

• You have an offer for a job that involves coding, or could benefit from it
• Existing tools don’t serve your needs well, or at all
• You enjoy it

“Learn to code” is the common refrain for what to do when you’re poor. It’s misguided at best, malicious indifference at worst.

I had a problem trying to learn to code: I mastered all the syntax of a language, got comfortable understanding the standard library documentation, followed guides on applying common frameworks and libraries.

And then…

Well, what next? I can do it well enough, but all my hobbies have great tools already. None of the open source stuff I might contribute to comes close. I’m not going to make something to compete with Ableton Live. That’s BitWig Studio, and I have no plans to switch.

And no one will give you a programming job in the current environment if you don’t have a GitHub bursting with personal projects. So doing it as a job is out as an option if you don’t lean that way. Some people enjoy it and have no problem filling out a GitHub, or they have enough problems with the tools available to them that hacking on them is the best path forward.

Most people will not make a better living programming than they could pursuing things they actually care about. The people at the top levels of the field are hard at work coding themselves out of a job by lowering barriers. This is a good thing for society, but it’s bad for salaries. Accessible means more competition: it opens the field to people who maybe aren’t brilliant with syntax, but can piece together elegant or at least functional solutions from off-the-shelf components. The gold rush is on the way out, and “programmer” is turning into an actual job and losing its value as a status symbol.

There is a future, probably not far off, where the shine wears off and it’s enough to be able to pick up syntax quick. Where companies hire for ability to learn and do the job, not ability to pass gatekeeping exercises.

But let’s say you’ve decided to forge ahead and learn to code. Here’s some tips.

Behind “where do I start with programming?” is “what if I pick the wrong language or framework?” For every possible path, there are fifty popular tracks. I think this overwhelm is a problem of approach.

No one tells you that it’s impossible to know which path to take before trying a few. You have to learn how to make a loop and instance a few objects or toss a few functions around in different languages until you have an idea of what appeals to you, and what well-worn paths or broad fields you can explore with those appealing aspects.

Other people’s opinions—theory, tutorials, forum posts, reviews, podcasts—are for when you have enough experiential knowledge to tell whose advice fits your needs and inclinations.

So that’s it. Pick a language. Mess around in it. Make some toys. Pick another language. Repeat. Like that framework? Goof around in it. Does that tutorial video look promising? Watch it, then see what others said about it.

Given enough time, you’ll get a sense of what you gravitate toward and discover the magic words to find other stuff that employs the bits you like. Then, and only then, are you prepared to get something out of some Elder Programming God’s treatise on Python bytecode. You aren’t ready for Python bytecode. Experts in Python sometimes don’t even know there is a bytecode.

Did you know Python list comprehensions and their expanded equivalents compile to bytecode with different performance profiles? Down this treacherous path lay premature optimization and wasted time until you know what to do with that knowledge, or if you need to do anything.

Go play. Have fun. You used to get this when you were a toddler. Did you worry about who had the best take on toddling form? Of course not. Be like a toddler and bump into things at random until something clicks. The sheer wall of frameworks and languages and platforms and tools doesn’t exist until you’ve picked enough at random and played with enough to filter the pile into something you can reason about. Then you realize the wall is a staircase that branches off in different directions.

Your assignment: pick a language. Find some way to apply the different patterns to something you care about. A good clue is to see what libraries are available for that language, and how many target your interests. Try to implement one! Can’t find any? It’s a harder road, but someone had to make the first library. Maybe you’ll start a trend. Maybe you’ll figure out why no one wrote a library. You can write and publish a warning for others.

• If you like listening to music, find a library that cracks open audio files and reads their metadata, then do something useful with it. Can you out-do Spotify’s recommendation algorithm? Look up how to make a K-nearest neighbors (KNN) algorithm.
• If you make music, build a tool to open your project files and see which chords you use the most. This one’s trickier than it seems. Answering “what is a chord?” fills books.
• If you’re a writer, do some statistical analysis on your writing and see what insights you can pull out. See where your findings meet, diverge from, or clash with the writing advice people give.
• If you’re an artist, crunch the pixels and see which colors you use the most. Try to generate a set of pallets and compare what’s “right” in color theory to what you make and what looks good to you.

My advice to you, is to stop listening to advice until you know what to do with it. Do first. Find what you enjoy, then what you can do with it, then how you can do it better. Some people enjoy programming as a hobby, but for most of us it’s a force multiplier. We need something to multiply.

After that

I am going to be honest with you: if you fully intend to make a go at this, you need to eventually have a passing familiarity with what nerds like to call idioms, patterns, and algorithms. Or something to that effect. Roughly translated: all the ways to do stuff that other people found after beating their head against countless dead ends.

For example: you’ll often encounter advice in the form of “don’t roll your own…” and it’s most often attached to cryptography. But only because the hazards of getting encryption wrong are higher than with most things. Find the patterns. Find the idioms. Find the algorithms. Find the well-documented pitfalls. Then roll your own, if that sounds like fun, or if the existing stuff doesn’t fit your needs.

You’ll want to know this stuff eventually. Play, practice, have fun. But as you do, seek out a good book on common programming patterns. Things that transcend programming language tend to be called patterns or algorithms. Your bubble sorts and recursions. Languages often have their own word for the way things are done in their community. If you’re exposed to online games at all, you’d call this the meta. And like in games, it’s always evolving. In Python, for example, things in line with the meta are pythonic. For languages without a word, idiomatic is the term. So if you want to find good ways to do something, search something like “idiomatic way to do [x] in [y language].” This is the stuff that most people get bogged down in trying to learn. Any good guide will cover this stuff, but do follow up with other perspectives. Truth comes out when ideas clash, but you don’t know what truth looks like yet.

Concerns about efficiency and security, which the meta generally focuses on, don’t really apply until you post your code up for others to use.

One caveat: there are different ways to mangle and manage data, and computer science has a good handle on what to use and when. I had a great list of these algorithms bookmarked somewhere on GitHub a while back that gave a rough overview of the common algorithms and examples in popular programming languages, but it went missing. You can guess and fumble your way around for writing personal code, but you should look up battle-tested ways of handling data for anything you let other people use.

Spend enough time with programming and you’ll encounter the notion that programming is really data design. Code is just the glue that connects and works with that data. When you get right down to it, we’re flipping little switches in silicon. Some of those switches represent information. Some of those switches represent instructions. Picking types and formats and structures as you code rather than planning ahead can lead to problems later. Don’t fret it too much right now. Just revisit this notion in the future.

Wikipedia has a huge list of algorithms you can do a page search on (Ctrl+F in most browsers) to find something suitable for what you’re working on. It’s more unwieldy than the list I had. Most languages implement these in their standard libraries, and they’re made by people who know computer science and practical programming, so you probably won’t improve on them by rolling your own implementation.