Can you teach me how to code? Why my answer always starts with no and end with yes

Can you teach me how to code? Sit me down and flip open a book, going from beginning to end like a textbook? Can you teach me to code, so I can make games and maybe hack the Pentagon? Can you teach me to code, so I can make millions and billions, doing almost nothing but drag and drop?

Can you teach me to code?

The short answer, my young dreamer, is no.

The long answer is yes — just not how you want me to teach you.

The thing about code is that it’s not that glamourous. It’s long hours, days and nights spent arguing with a computer and the computer is always right. It’s a one-way relationship, with Google as your companion, and maybe a Stack Overflow friend.

It’s a series of one confusion after the next, silent failures and red errors.

Why?

Because code is a language and languages are tools of communication. You can route learn code, but to create something out of it — well, that’s a different story.

It’s the difference between tracing and learning to draw. Anyone can trace a picture, but not everyone can draw. The ability to draw includes the ability to identify shapes and replicate them on a medium. That’s what coding is — a process of identifying the different necessary parts to make a system. After that comes creating the pieces, the struts and the beams that make up the application.

When you code, you are the builder and the architect, the mastermind of your little plot of sandbox. But like in real life, you can’t just build a house and call it a day. There are resource consents, council permissions, engineering reports, provisioning, and even the weather forecast to take into account. The equivalent to this is your project manager, client demands, team member’s opinions and thoughts, and legacy code (if you’ve got any).

Over time, you find yourself spending more time in the process than the actual code itself. It’s easy to create code when you’re by yourself — but that’s rarely the case. Your work is absorbed into the multitude of moving parts that are supposed to work together like a seamless machine made of digital cogs mostly encased in curly brackets. Sometimes it gets edited by others, morphing into something completely different within a few months, if not weeks.

So can I teach you how to code?

Probably not — not the way you want me to teach you — the linear point A to B, x = y = z kind of formula. I’m not that kind of teacher.

You probably have a project in mind, a dream that you want to fulfill, an app, a game, a something that will materialize if only you knew how to code. Let me tell you this, you’re doing it backward.

If you’ve got an idea, work out the bits and pieces first. Figure out what you need as your features, why you need it, and how it's going to work. Figure out how the bits and pieces to group together and the relationships between them.

Then you can start coding. Pick the smallest set of features — the minimum collection of things you need to get your app, dream, idea running. Then jump right into it.

Get it working as quickly as possible. Learn to fail and fail often. Become friends with failure. Once you do, every time something falls apart, you get better at picking yourself up. You learn to fix things faster and recognize your potential failing points before they happen.

Because coding is nuanced to the language you choose. Learn the technical basics and get creating as quickly as possible. Read around topics that can supplement your app, dream, thing. Look up patterns. Create a series of dots that will eventually make sense.

And trust that these knowledge points will eventually make sense.

Code is a tool. It’s not some magical thing that will make all your dreams come true. Code is a thing that only materializes properly if you are clear on what you want to achieve from it.

So can I teach you how to code? Probably not.

Can I give you some of the pieces of the puzzles that you might need? Probably yes.