One of the most challenging goals I set for myself this year was to learn to code. As a business and policy wonk, I’d never had any experience whatsoever with coding. Like math (something that I’m completely terrible at), coding seemed like this huge mass of knowledge too confusing to understand. Why bother learning something as difficult as coding?

A couple reasons compelled me to actually start coding. First, CodeYear did a great job with marketing their efforts. It seemed like everyone and there mother was making 2012 the year they’d learn to code, and Code Year was going to make everyone coders. Second, I’ve always had an interest in innovation and technology. Learning to code, in my perspective, seemed like a natural progression. Third, and most importantly, is that I viewed coding as a way to make products – in the form of applications – for public consumption.

It’s been a year, and I’ve certainly learned a lot. I’ve yet to launch a fully operational web application, but I can honestly say that 2012 definitely was the year that I began to code. After a year of starts-and-stops, here are my three takeaways from a year trying to learn to code:

1. Know why you’re doing it. I began coding because I wanted to have the ability to create great products for users. It was hard to keep this in perspective though, when I was struggling with just the basics. I think what kept me going throughout all those long hours spent in front of the screen was the fact that I genuinely actually did like the process. Specifically, I liked the fact that coding was about problem solving, it allowed for a lot of creativity, and it was just plain cool being able to create something!

2. Persistence. If you’ve got a good reason (the more reasons the better), stick to it. It helps when you have clear goals so as to have clear indicators of progress. For me, this was relatively easy since I was working through courses.

3. Know when to quit. If you haven’t already, check out this great speech by HBS Professor Deepak Malhotra on quitting early and often. It’s a little lengthy, but essentially Prof. Malhotra argues that if things aren’t working out, quit. Obviously, quitting is pretty much the opposite of being persistent, but I think it’s all about context. When in doubt, re-evaluate and act. For me, even though my coding goals were vague beyond completing a course or module, I never gave up because I found coding fun. If it isn’t fun though, or there aren’t any pressing reasons to continue, quit.

So, those were the three takeaways that come to mind as I look back on this year when I began to code. I’m pretty sure I’ll continue to develop my coding skills in the new year, but I’ll definitely need to solidify my coding goals going forward. Here’s to hoping that 2013 will be the year that I take coding from just a side hobby to something more!