Friday, January 4, 2013

100 Programmer Resolutions For The New Year

A few days ago saw a tweet from Kevin O'Hara (who builds things, with code, for people) with a link to a blog post containing his 2013 programmer resolutions. Something struck me about this idea, I'm not one for resolutions but I always have a list of hobby-code intentions as long as my arm, and the new  year does seem like the perfect time to write them down. I asked Kevin if I could borrow the idea, to which he agreed, and so here they are: my programmer resolutions for this year, and hopefully I'll complete them before January rolls around again.

1. Learn More ARM Assembly

When I finally got hold of my Raspberry Pi I was very excited about the idea of finally having a good excuse, and device, to learn more about ARM assembly. I've had an interest in ARM chips since working on the Nintendo GBA & DS, though back then I was working in C and only ran into peculiarities of the chips when trying to do things like loading from unaligned addresses. I have been interested in Operating Systems since I first laid eyes on BeOS, and have always been fascinated by the idea of building one, so I was over the moon when I discovered a tutorial from Alex Chadwick: Baking Pi - Operating Systems Development. I reached the stage of drawing to the screen but then Dreamforce,  holidays and my wedding distracted me somewhat and currently there's a bug which prevents it reaching the render loop, so step one will be finding and squashing that.

2. Contribute to Haiku

I've talked about Haiku here before, and although I've followed the project from the very start my own contribution has merely been a screensaver, and one that only worked at certain colour depths at that. This year I want to make use of the newly-defaulted graphical debugger (I was never much cop with GDB) and start working on that platform some more, either building an app or contributing directly, but either way I just want to help those guys out some more because it's an incredible OS and a hell of an achievement.

3. Finish A Game

A recent (i.e. several months old) screenshot of the prototype mentioned.
Earlier in the year I set myself the challenge of building a game prototype in a weekend, and to a large extent it was successful. Over the weeks following that weekend I completely changed the look and feel of the game, and ended up with something cuter, but crucially it never progressed past the prototype stage.

This year I want to take that prototype, develop it and get it released, because it's been far too long since I really got stuck into a game project.

4. Continue To Participate In The Community

Goes without saying. This is not last because it's the least important, it's just the only one that is tied directly to what I do day to day, which should make it somewhat more achievable than the above. The last year has been amazing and the willingness to share and teach of those involved constantly blows me away; we've got a great community and I intend to keep doing all I can to do my part.


I really hope that I achieve each of these goals over then next year, but time will tell, as will updates on this blog as the year progresses. Happy New Year!

Related Posts


  1. ARM is an awesome architecture and the more you get to know it the more you'll grow to like it and the better your C code will get. Everything is very logical, compared to x86 at least. I love being able to use the barrel shifter on pretty much any instruction and using ldrex and strex to implement atomic operations is the most flexible solution I've seen so far. I'm not fond of x86's lock extension. One of the guys at work had the ARM System Developers Guide: Designing and Optimizing System Software. I had a skim read of the book and it seems like a really good read. It delves into the ARM core in quite a bit more depth than the ARM docs, which are essentially just an instruction reference. In the book there is a good section on writing efficient C code for ARM with some tricks of the trade to make C compilers lives easier when compiling down to ARM. It was really light on the things that you'd mainly drop down to assembly for, i.e. the use of co-processors such as vfp or neon units but after reading the book you should be able to use those extensions easily from just the ARM docs. A lot of ARM processors still execute in-order so actually doing a bit of assembly in the right place can be really worthwhile and get you some really large performance gains. It's only when out-of-order units come into play that your efforts as a to the metal coder can be disappointing to say the least.

    1. Looks like I've got yet another book to purchase! I've got a backlog of about 5 computer science/hardware books to get through already!