You wish for a convenient way to make sure you actually sit down and practice JavaScript on a regular basis, and as if by magic, Code Year arrives.
As I type, we are in the middle of Week 3, and so far the lessons have mostly involved getting to grips with basic programming concepts and typing them out over and over and over again.
Each week reviews the lessons from the previous week, to make sure they are thoroughly hammered home.
I, for one, am finding that an extremely useful approach. I have more programming books than I care to admit impulse-buying, and many of them have a tendency to cover all of the basics in Chapter 1, and then go 'got all that? excellent, now let's use absolutely all of them in a slightly vague context'.
I exaggerate slightly; but only slightly.
I think that one of the things that is particularly easy to neglect or underestimate when talking about teaching a beginner something that you yourself know well is how difficult and important it is to become comfortable with the language.
You can't write before you can read; and you can't effectively engage with a problem if you don't have a vocabulary to construct a meaningful response.
Take music, for example.
The first five grades of music theory are largely an exercise in learning how a (classical) score is constructed. It's learning all the elements that go on to the page, how they are organised in relation to one another, and how they translate into physical action.
You can pass grade 5 theory without playing - or, indeed, hearing - a note. You'll learn a lot that you'll only half-remember, and it sure as hell won't make you a musician.
The point of doing it - and the reason why grade 5 theory is and should be a prerequisite for the higher grades - is that if you can look at a score and understand what the lines and dots are asking you to do, that frees you to think about performance and interpretation without getting caught up in deciphering the basics.
So it goes, I find, with programming.
One of the things I've heard a lot is that the way to learn is to find a problem that you really want to solve and figure out how to do it. Much as I agree that you only really retain information if it is useful to you, there are in my experience a couple of problems with that approach when it comes to anything that is, essentially, in a different language.
Firstly, if you're building with no foundations, that's going to affect the finished product... as most of the websites currently on the internet can ably demonstrate.
I was recently involved in organising pre-interview skills tests for a junior web developer position, and some of the HTML pages they sent through looked fine on the screen but were built like a house of cards. The smallest change would plunge one into a whole afternoon of rewrites and swearing.
The thing with front-end development is that practically everyone dives straight in and builds a real website. That's one of the things that makes it so exciting: within hours, you can have the website that you wanted. It might not be perfect (okay, it definitely won't be perfect), but it will be there, something that you built yourself and people around the world can see.
However, if you then want to build a good website, you'll probably be looking at unlearning a lot of cheap hacks.
It also goes without saying that the same 'dive in and build what you want' principle translates far less well to a first programming language than it does to HTML, unless what you dream of is, say, a way to generate random numbers from 1 to 6. The level at which the fun stuff starts is unavoidably higher.
Secondly, my experience has always been that I do not use JavaScript very much outside the usual bells and whistles, because it simply doesn't occur to me as an option. I'm not familiar enough with its capabilities to look at a problem and think 'aha, JavaScript'll get around that one'.
It's like all those weird and wonderful bits of twisted metal that you see in cookery shops. If I knew what they did, they might transform my kitchen experience. I don't, so I solve everything the messy longwinded way with whichever knife comes to hand.
This is where I think Code Year is so far working well for me.
Three weeks sounds like a long time to be repeating the basics, but the basics are sticking; and while the example programs have all been extremely simple so far, I can see how they work as building blocks for bigger things.
The other criticism that I have seen regarding Code Year has focused on the relative lack of formal teaching/pedagogical theory, and while I can to some extent see where they are coming from, I think they are also missing the point.
Code Year is, in essence, a tool offering structured practice. It's 'teach yourself', with everything that that term implies: you're given the starting point, and it's up to you to work through it in a thoughtful way.
I have seen people ask what they are supposed to learn by copying and pasting to win the little reward badges, to which I can only reply, why are you copying and pasting?
Typing things yourself and working out where you've made mistakes is how you learn. If you game the system to get badges faster, do not then complain that the badges aren't magically conferring wisdom.
I realise of course that, like all personal challenges, it's probably best for confident self-starters - and as a home-educated OU graduate, I take self-starting to a pathological level.
That said, I think that the Code Year interface is fun and friendly enough that I would feel pretty comfortable with recommending it to a lot of people that I know.
And in the meantime, I'm enjoying feeling as though I'm making some real progress towards something that's been on the 'to do... tomorrow' list for some years!


