I’ve been asked a few times now how to learn to program. My advice has varied as I’ve continued thinking about this, but I’ve recently realized the answer has very little to do with programming itself:

There’s something you need beyond just knowing a particular language. It doesn’t matter if you stay pure with Haskell or find your one true way with Python; it’s irrelevant whether you focus on embedded systems or concentrate on infrastructure at scale; and it certainly doesn’t matter whether you end your day with :wq or C-x C-c.

If you want to learn to program (or get better at just about anything), you need to be curious and unafraid. You should frequently arrive at the brink of your knowledge and constantly immerse yourself in the depths of each cliff.

–

I was fortunate while growing up that my parents ran a computer-based business out of our house. The Macintosh was new enough (at least for St. Louis businesses) that there was no computer store to call. For a business, this is no excuse: a misbehaving computer could not lead to a delay with our newspaper or any of our clients’ printing jobs.

Recognizing that truth, and aware that we couldn’t rely on any local shops for help, my mom bought a huge book on computers and taught herself how to fix the machines as issues arose. My parents quickly learned to stock up on parts (as some organizations took to abandoning their aging or malfunctioning machines, we stocked up on those pieces to fix our own equipment).

As I was growing up at this time and paying close attention to the world around me, I absorbed this one important lesson from my parents: to not be afraid by the possibility of a computer breaking, but to instead relish in its resiliency when it did.

My parents made sure that I grew up on these ideas. With spare computers all around the house, I was encouraged to play around on any machine and not worry about what might go wrong. If I clicked the wrong icon or tugged on a cord that should be left in place, I knew that it’d just be a temporary blip: my mom could fix the computer and I’d pick right back up where I left off.

I’ve carried this throughout my life. In school, of fifty math problems, it was the one that had me wracking my brain for hours that stood out; when I studied taekwondo, it was my sparring partners that knocked me down that had me excited for a rematch; and with programming, it was the symbols that looked most foreign that reminded me how my time with computers was just getting started.

–

It’s the unknown that can keep us on our toes. If you’re just learning to program, you might look at something like this:

1    public class Hello {
2        public static void main(String []args) {
3          System.out.println("Hello, World!");
4        }
5    }

and mutter a few curses about whatever the hell a public static void is.

Great if so! The most important thing is not that you immediately know what all of these words mean; instead, it’s that you be slightly irritated by not knowing. Once you’re ready to start exploring those unknowns, just remember that there’s very little you can really break, so don’t worry about what could go wrong – try it anyway and see what happens.

If you can master being aware and bothered by the constraints of your knowledge, then you’ll always know when it’s time to push your own boundaries and you’ll have the drive to do so.

So go on. Give it a try.

Thank you Alex MacCaw and Patrick Collison for reading my drafts.