coding as play

Side projects are important to a programmer. They are often the only means for expanding skill sets outside of work or school lives. However, side projects can be straining for those with limited spare time and many of them often go uncompleted.

I look at my personal completed side projects. The ones that are finished I either worked with others to complete or the project had a very limited scope which made is feasible in a short period of time.

XOmBot was one of these projects. It was originally written in perl and handled very few IRC commands. I still actively add to XOmBot 4 years after it’s original creation. It’s adapted quite a bit in that time and thanks to the help of a couple of friends it is now a ruby bot that uses Cinch and has a number of contributors. This is something I count as a successful side project despite limited initial goals.

However, not all things that help your skill as a programmer need to be side projects. There’s huge value in approaching code with the idea of playing rather than hitting some predetermined end goal. It’s something I used to do quite a bit when I was first learning to program: I would find some chunk of code online throw it into a compiler and keep tweaking and playing with it until I either came up with something interesting or found some new way to make it crash. Now it seems every time I want to play with a technology or learn something new I try to create a project with the correct parameters to achieve that goal, but that’s unnecessary.

Play is extremely valuable to learning. I recently experimented to get myself back into the mindset of playing with code not to achieve some set goal, but just toy around until I made something happen that I liked. I purposely picked a language I hadn’t used since high school (qBASIC) since it really has a lot of great aspects for play built right into the language. Drawing and making sound in qBASIC is dead simple and thanks to QB64 qBASIC is given new life on modern operating systems.

In the end I came up with keyboardtime; a name that probably came from my desire to play BurgerTime. My initial goal with it was nothing and had I meant this to be a serious project I probably would have looked up what a keyboard looks like or what notes go where, but for this I didn’t care (I did look up frequencies for notes because trying to guess would be a terrible exercise in brute forcing). My goal was to make something that ran and did something I liked and in the end I learned how to do something I never knew how to do before. I had never created a mouse cursor in qBASIC.

I had never dealt with coping with flickering when drawing in qBASIC before. I had never even thought about messing with creating anything music related before, but I did all these things in the course of play. It was just a flow of ideas and rather than fighting it and anchoring myself to one particular path I went with where the ideas were taking me. There’s massive value in this. It’s an experiment. It’s play. It ends up being immensely fun.

The steps are simple:

1. Pick a technology or language and work within the confines of that language
2. Don’t set an end goal
3. You are done when you are done (if it stops being fun, stop.)
4. Forget tests, forget best practice, just make something
5. Have fun