Learning is a very subjective matter and surely there are many different ways one can improve her skill, ranging from attending lectures all the way to open your favourite editor and hack randomly until you get it. Anyway, no matter how you learn the craft, the goal of practice is to add new tools to your belt so your can deal better with Real World™ problems.
Much easier said than done, though. There is often a wide gap between what you learn “by yourself” and what needs to be done in a production environment: that new technology/pattern/feature you just learnt of might look so cool that you really have to use it everywhere, just to find out some time later that your approach was too naïve and needs a rewrite, or that the technology was just not suited to the problem and you need to switch back to the old one, or that the guy who’s in charge of support really does not have a clue of what the code you wrote is supposed to do (you know, the fact you are willing to give up some of your spare time and learn new things outside work doesn’t mean everyone is).
One of the ways you can find out if you’re doing something that makes sense outside your devbox would be to go and take a look at what others have done in a similar situation and – guess what – open source projects are a great source of tested and reliable code, but the size of the projects can be sometime overwhelming: at first you just don’t know where to start looking and, without a sound approach, you can spend a lot of time before finding out how a feature is implemented from start to end.
I’ve been delving into open source code for a while now. I didn’t find much guidance around so I had to learn the hard way. I hope the following tips will be of some help to you:
start from tests – tests are often a great starting point: if they’re well written you can understand what a method is supposed to do without even looking at the implementation. You can use tests as they were a map (or an index) of the project.
start small – pick a minor feature at first, or even just a method if you can’t find a feature small enough. It might not be extremely interesting to know that datamapper checks for properties to be present on the model before querying but at least now you’ve got an handle, you can explore deeper from there.
when in doubt, debug – more than often the code will be not clear enough or not commented enough to be understandable. In those case debugging a test makes everything easier: both VS and NetBeans have great debugging capabilities, if you don’t know how to take advantage of the debugger already I strongly suggest you to learn how to. If you are debugging ruby with NetBeans you should install the gem
ruby-debug-ide for greatly improved debugging speed.
tinker with the code – a great way to know if you’ve learnt your way into the project is to make some small changes and see if the resulting change in behaviour is the same you were expecting. I suggest you to implement your changes strictly with TDD in this particular case, and to make sure all the project tests are green before and after your modifications so to lower the chances of creating uncatched side effects.
bug fixes come later – I believe that rushing through the learning stage and trying to create a patch to submit without having a deep understanding of the whole project first is a waste not just of your time but also of the guy who is checking your broken patch, so get a grip on your ego and take it easy. I think bug reports are much more useful to submit, and if you’re learning the right way you probably will have plenty of them to send in much before the time you are ready to fix them yourself.