Want to learn to code? Start here.

Last September, I wrote a post called Want to learn Rails? Start here. which has been pretty successful. I’ve met and emailed a good amount of people who have follow up questions or are in the middle of learning how to build things with software. I’ve referred a bunch of people to the post as well. I’m proud that the post is actionable and helpful. Since I wrote that post a while ago and developed my engineering skills much, much further. I wanted to write a follow-up post, some revised thoughts on learning how to code.

This post is intended for working professionals who feels a strong desire to code to build things that they want to see exist in the world. This post is not intended for the person who thinks they should code because they hear so much about it. I mean no offense but I’ve found those people to be lacking in the short and medium-term fire it takes to learn to actually build software.

1) Nights, weekends are bad

Given my personal experiences and a slew of conversations, I’ve found that learning how to code only on nights and weekends is a terrible way to go about it. When your brain is not trained to think the way coding forces you to think, it’s very easy to lose where you were or not remember a key concept you just picked up. Putting in as much time as possible is your friend.

This point of view is reinforced by programs like Dev Bootcamp which not only require a full nine weeks of your life but also make you pay tuition to attend (which is not a small sum). They make you buy in temporally and financially to ensure your success. You have to throw yourself in or you will fail.

2) Forget Codecademy

“I’m learning how to code! I’m doing Codecademy!”

I don’t know how many people tell me this. If I follow up with any of those people six-to-eight weeks later, they’ve fallen off the boat completely.

Here’s why Codecademy doesn’t work in the long term:

3) Have a real project you want to build

Have something tiny you want to build. One of my first projects was called Today I Learned. It’s a text box that you enter stuff into and it shows the date you entered it in descending order. That’s all it does.

Your first project is going to be crappy. But it will be done. And it will be done by you. And that’s fucking awesome.

4) Everything you build, builds on top of the stuff you’ve built before

I built Today I Learned and whatever I built next, was better because of one or two concepts I learned while building TIL. You’ll constantly be referencing your old code, code other places in the codebase or code from the Internet, once you understand what the pieces mean.

5) Don’t copy and paste others’ code

Tommy Nicholas wrote a post in December which echoes the same point. You learn things when you write code out. You question what certain pieces mean. Hopefully you Google those questions to learn more and understand more.

6) Stop telling people you’re learning to code unless they’re technical and you want them to help you

When you’re starting out, your goal should be to find a technical mentor or two, not impress your other non-coding friends with the fact that you’ve taken the first step.

I’m a firm believer that if you talk about what you want to do, you never actually do it. So unless you’re talking to someone you hope will be a mentor, close your mouth, put your head down, and keep building.

Loose lips sink ships

7) Coding is failing a ton and understanding why. It’s painful and frustrating

The way you learn how to build software is by making the same mistake a few times, learning why that doesn’t work, and doing it correctly. The next time you come across a similar problem (and trust me, you will), you’ll either remember the way you did it last time or at least the part of the codebase that you struggled in, which you will then reference and remember what you learned from all of that failing.

The rewards for building software are incredible. The feeling of “that came out of my brain” is what I live for. I love it. But the road to get to that point can be tough. Build momentum. Keep going.

8) Stop trying to figure out what you should do and just start.

A friend of a friend kept emailing me with a bunch of questions. He was trying to figure out all of the places he could fail before he even started.

That’s the absolute wrong way to go about this. Pick a language, (Ruby or Python) buy a really recent book that assumes you know nothing and just start. Do chapter one. Do it again maybe. The amount that you don’t know that you don’t know is bigger than you can imagine. Don’t worry about that. You’ll understand more pieces in time. We all will.

Good luck.


Now read this

BikeShare: a Ruby gem for Bay Area Bike Share

San Francisco is a fantastic city that suffers from some infrastructure problems. Most notably, biking infrastructure is pretty sparse. Of all of the ways to get around the city, biking is probably the best (and healthiest) option. That... Continue →