Code Year in Review

Like many others, I took part in Code Academy's Code Year over 2012. Was it worth it?

It was a day late, but I managed to finish CodeYear. All 50 weeks of it (and a Christmas card that randomly didn’t count).

Code Year

It sounds as if not many people did though. Kevin Roose over at the New Yorker wrote a public apology to CodeYear for not actually doing any of it. And he wasn’t alone. Some didn’t even open the emails. It all started with such a bang. This time last year, Sasha Grief knocked together a simple but compelling one-pager, while people such as Mayor Bloomberg (auto) tweeted their “New Year’s resolution is to learn to code with Codecademy in 2012!”. It was even reported by the Beeb.

Yet by the end, it had gone out with a whimper. Those that did finish on time got a nondescript email, and not so much as a badge of achievement, much to their annoyance. And there’s no sign of a 2013 track as of yet. Even the actual track is irritatingly incomplete: why would there be more courses? Surely the year is over? What happened?

New Track? Really?

In my opinion, the code year track got complicated somewhere in March with Javascript and never entirely recovered. I fancied myself reasonably competent when it came to JS, HTML and CSS, but I frequently found myself struggling with the lessons to the point of taking code directly from the forums. And that was before they threw Python into the mix at the end! The way I got through it was a couple of bursts of catching up (one in May to recover from jetlag, one in September, and then a final run in December) as well as the above cheating at times when the instructions were just too confusing. I’m not sure that others would have stuck at it. I had a couple of specific issues with Code Year:

  1. Variable quality and difficulty. Some lessons were not only difficult, but badly worded (usually the ones that had lists of complaints in the forum). More irritatingly, some lessons appeared to be out of order: what was an impenetrable concept in one lesson would next have its basics spelled out in the next.
  2. Vastly different languages. While it was a little confusing to move from JS to HTML and CSS (so similar and yet so different), at least they have a pretty similar basis. On the other hand, the final third of Python (moving to some pretty specific Python stuff!) was like learning a language all over again, given its syntax is completely different.
  3. A shift from what it said it’d be (namely being practical). While I found the final Python thread interesting, it certainly wasn’t what I signed up for. And while I found it useful to actually understand what the hell bitwise shifts were about, I struggled to know how I’d use that in a coding situation. (At the very least, an explanation of when it might be used would have been helpful).

Still, I did learn a few things:

  1. Fundamentals. The one thing I’d wanted to get from Code Year was to learn some of the fundamentals in regards to coding that you miss out when you only work on projects.
  2. A bit about that Google language. I had been playing around with the Python track when it was in dev, and did like it, until it took over the Code Year track.

Overall, I think I would have preferred Code Year to have stayed closer to Javascript and HTML (which is reasonably what most people will use), or either teach a bit of PHP (what a lot of us end up using, and closer to the syntax of HTML and JS anyway) or conversely show more to do with apps and APIs. That way, novices would be able to learn a new programming language each year, rather than a smattering of very different ones.

If they can do that and make more consistent lessons, then Code Year 2013 (if it ever appears) would probably be well worth taking.

Vicky Teinaki is a user experience designer at Newcastle upon Tyne agency Orange Bus. She is also working on a PhD at Northumbria University about better ways of communicating design methods within the design industry.