Small projects

There was a post recently in one of the forums I frequent about a new developer wanting to know what to do for a project. This is hardly a new question; the net is littered with remnants of first year CS students enamored with their new found abilities looking for ways to expand. In general, I suggest that a good way to build skills is to get involved with an existing open source program. The road map I layout is along the lines of:

• Pick something that interests you
• Start small (read and document some code)
• Tackle increasingly difficult bug tickets
• Develop portions (or all) of a small feature request
• Rinse and Repeat

I'll also occasionally mention that an alternative is to pick something that you do not like about your everyday computer experience and make that better somehow. It is this last point that I'd like to expand on here. Not that the suggestion is altogether vague, but an example always helps to illuminate a point.

In my reply to the post mentioned above I made the comment that I own a MacBook and that one of the features that I really liked about it was the dashboard dictionary/thesaurus widget. In case you are not familiar, the widget allows you to enter a word and get what is basically a dictionary listing for that word. This is directly available from the desktop environment by way of the dashboard.

I also mentioned that I frequently do work in a Linux environment and that I miss the availability of this type of tool there. My experience to define a word in Linux is to load up a browser and search for the definition on the web. I explained that this is the type of thing that you could use as a starting point for a project to hone your skills. In my case, I decided to write my own little command-line tool that would define a word for me. This is a far cry from a translucent, fly-in, dashboard widget but it gives me the immediate satisfaction that I'm looking for on my Linux machine. For example:

ezpz@sandbox:define > define "Ignoratio elenchi"
 the logical fallacy of supposing that an argument proving an irrelevant point
 has proved the point at issue

 Ignoratio elenchi (also known as irrelevant conclusion or irrelevant thesis)
 is the informal fallacy of presenting an argument that may in itself be
 valid, but does not address the issue in question. ...

The result, I claimed, was that I got added goodness in my Linux environment and learned a few things along the way. In fact, I found that not adding 'Connection: close' to an HTTP request can have differing effects depending on whether or not you sit behind a proxy.

It's important when you are starting out to set meaningful, attainable goals - even if they are redundant (i.e. another tool does something very similar). The meaningful means that you get something tangible (or at least relevant) out of the experience but the attainable ensures that you do not bury yourself in something you can not hope to achieve.

Sure, there exist tools that do what my little command-line tool does. Yes, they are way more sophisticated. That misses the point. I worked to better my experience, learned something along the way and now I'm a better developer because of it. And as for taking my own advise on the rinse and repeat - I've recently purchased a machine with Windows 7 installed and there is no dictionary gadget included by default. Looks like I'm gonna be learning some Javascript to build me a new gadget.