I know, I know, everyone and her dog is learning to code these days and probably half those people have breathless blogposts about Learning to Code. I'm about a month into my 3rd-ish attempt and it's going better than the last two times so... this is what's been working for me, I really hope it helps, your mileage may vary.
1. Little personal projects...
I've had a lot more success trying to learn from making my own little projects than I did (back in the day) with the various Learn To Code sites. So far I've made a Meep Translator, a randomiser for Politicians saying Kafka's Aphorisms, and a quiz about which website gets more traffic. Each of these sites is really, seriously, incredibly dumb/trivial:
But in terms of learning to code, I find these things immensely more motivating than doing the exercises on an online coding site (on the one hand) or trying to do a big personal project (on the other hand) that won't have anything to show for weeks or months. And motivation is really important when you bang up against a problem that you don't know how to solve and find that your code isn't working no matter what you do. I feel like I learned the most when I had one or two of those hard problems left but I didn't want to give up because I was so close to having a fully working programme (even if that programme was just a fully-working Meep Translator). I didn't have that drive when working on coding exercises, but it's hard to keep going through all the obstacles that accumulate in a big personal project when you're just starting out.
2. ...that work at every step.
Some of the best advice I ever saw about coding came from Christina Cacioppo – the whole post is gold-dust. One thing she says is:
When programming, the thing you’re making won’t work 98% of the time. In other disciplines – say, writing an essay – your thing isn’t broken most of the time, even if it might not be good. It’s odd in the beginning, but remember that things being broken, not just bad, is a characteristic of programming – not you.
The main thing I took from that is that, early on, it's nice to work on projects that will work as often as possible. In some ways this is an artifact of doing small projects instead of big ones, but it's also a matter of the approach you use and trying to break down your projects in such a way that 1) you have something that works, in the dumbest sense of "works", as quickly as possible, and 2) each feature you add from there still gives something that works.
For the Meep Translator it was "a programme that prints the word Meep on the screen when you press a button", then "a programme that prints the number of times you've pressed the Meep button" then "a programme that prints item X from a list when you press the Meep button X times", etc. etc.
While I sometimes had to "break" my programme briefly in order to add a new feature, I tried to keep those stretches of broken-ness as short as possible. This is probably not possible when you're doing bigger projects, and my feeling was basically that I don't yet know enough about programming to cope with a project that's broken for long stretches of time. One of the biggest problems there is that, early on, you don't know if something is broken because you're doing it completely wrong or if something is broken because you forgot one frigging semi-colon. So while I'm looking forward to the point where my brain can cope with a big elaborate project where the pieces intersect in complex and multi-layered ways, I don't think it's worth kidding myself that I'm at that stage yet: at the start I think it's good to work on very simple, linear projects where each new feature you add just sits simply on top of the work you did previously and makes your dumb little programme a tiny bit less dumb.
3. Lean hard on StackExchange, and also bug your friends
Searching for things is a surprisingly powerful/effective learning technique, and accepting how much you can learn just by searching the right few words seems like a pretty useful/important lesson in itself. It works in spurts – sometimes the answer will just give you some code which might be functional but which you don't actually understand, but sometimes the answer comes with a good explanation and over time you patch together an understanding of the underlying principles. The experience of learning to code in the age of search and StackExchange feels like it teaches me a lot about learning, at a fundamental level – it feels more like the way (I think, very fuzzily) children learn languages and such, just from seeing a lot of examples of things and patching things together and trying things out and improving. I wish there were as many resources for learning other things that way.
All that said, one of my big fears from learning-by-search (and one of the attractions of structured coding exercises, or even Coding Bootcamps) is the fear that you'll end up learning bad coding principles: my sense is that it's easy to kludge together programmes that work, on their own terms, but which get you into bad habits that you might regret later (making mistakes that have already been made a thousand times before, and which a competent coder would advise you against). So I think it's really helpful, if you have lovely friends who can read your code and give you high-level advice about what you might be doing that just-about-works but isn't optimal in the long run. I think this is a much better use of your friends' precious time/attention than "how do you add an element to the end of an array?", which (as previously mentioned) can be answered perfectly well by StackExchange once you learn not to panic too much when it doesn't work the first couple of times.
4. Use GitHub and GitHub Pages (for hosting)
Github looks really intimidating from the outside but it's really not hard once you get into it – if anyone has a recommendation for a good Getting Started with GitHub Guide I'd be happy to post a link here, let me know. [UPDATE: The excellent Michal S. recommends this GitHub for Beginners Guide from ReadWrite. Great info presented with simplicity and friendliness. Recommended!]. But beyond the joy of version control (which is probably more useful when you get to a much higher level than I'm at (and when you're collaborating with other people), GitHub has a couple of great advantages that are totally under-appreciated.
First, GitHub Pages is this crazy amazing service that just hosts your frigging webpages completely for free and lets you do a bit of coding on your "Main" branch and sync it easily with your "gh pages" branch once you're sure it actually works. (Again, if anyone knows a good guide for this I'd love to post it because the official GitHub Pages documentation I think makes it look like it'll be more work than it really is).
Second, GitHub tracks how often you "commit" code and tells you how long your current coding streak is:
And yeah, it's just implausibly motivating to have that tracker going and to watch those little green squares build up over time. Somehow feels more real and meaningful than all the gamification elements on all the code-learning sites put together.
I'm about a month into learning to code again, so I don't really know if I'm learning well for the long term.
* Note: I don't actually lift weights, myself, so I can't say whether this is good advice when it comes to actual weight-lifting. I like the metaphor, though.↩
Limited time only: Get a free copy of Write Harder + (very) occasional & thoroughly excellent emails.