Debunking the “Conspiracy” around Learning to Code
When people want to learn to code—whether testers, business analysts, or high school students—they often turn to one of the million learn-to-code sites. Smart people, trying to be helpful, contribute to these sites, but they believe the reader is like them, so they show a list of buzzwords and a solution, assuming the reader will follow right along.
Except typical readers can’t. They are instead overwhelmed, feeling a bit like they've been dropped into the sea with no life raft. “Good luck! It’s easy!” say the voices, pointing out that all the readers have to do is learn HTML, JavaScript, half a dozen responsive design libraries, version control, a REST API …
About this time, the casual learner gives up.
Then there are the free introductory learn-to-code websites, which get you started fast writing for loops, conditional statements, and print. That’s great, but compared to the vastness of full-stack development, it is a bit like teaching people to draw stick figures and then saying, “Good luck with the Mona Lisa.”
It is as if there’s a great conspiracy attempting to make writing code look hard and intimidating. I say this not as a programmer (which I am, at least part time), but as a writer and teacher—as someone whose role in society involves helping transfer ideas.
Don’t worry; there is no actual conspiracy—only people afflicted with the curse of knowledge. That means that because they do know how to code, they can’t imagine what it is like to not have that skill. The tutorials, the advice, and the steps all make total sense if you know how to code, but the problem is that you don’t.
Then last week someone sent me this video on learning, by Kathy Sierra. In twenty-three minutes, Kathy explains two major problems with learning and implies a third. First, when we are learning too many things at one time, we can’t make progress, get stuck, and give up. Second, humans tend to learn by repeated experiments, such as code katas, done about fifteen to thirty minutes a day for a month rather than twelve hours a day over a weekend. Then she implies that we learn through multiple examples better than through theory.
Most CS books do things in a different way; they teach you the theory, then give you a problem to solve. Not all, though. Zed Shaw’s Learn Code the Hard Way teaches programming the way most people learn music: by hitting the keys, seeing what you just did, then having it explained. This way, you’ll teach yourself the basics of programming, which is a bit more than stick figures.
So, that’s my advice. Add some consistent time every day to experiment with a very small scope: one programming language, one chapter a day. The version control, the code library to drive the user interface, the build/deploy pipeline, the unit tests—they can all wait. Give it a good try. If it’s fun, do more of it; if it isn’t, do something you enjoy.
For now, I’m going to get good at the bowling kata in Ruby. Join me?
