Thankfully when I finished reading Practices of an Agile Developer I didn't feel completely despondent.

My career, at least for the last twenty or so years, has been as a software developer (I'm still searching for that elusive second career). So I couldn't help but relate the advice and tips given to my previous, or indeed, my current employment situation.

It's good to read that ideas that I've implemented over the years are the same best practices that the book describes: using a version control system, writing build automation scripts and having a central ticket logging system. The one thing that I don't do is keep a log of what I've worked on, the problems I've come across and how I've solved them. That's something I need to start.

One sad point is that never in my career have I polished or re-factored any code... ever. From that little nugget you can also deduce that I've never written any automated tests, which are the bed-rock of re-factoring. It has always been the case that as long as it works that's it.

It's a good, easy to read, book that I didn't really get all that much information from. Possibly because I've read so many development books and blog posts over the last few years that I've heard most of the advice that's given. If you are just starting in a career as a developer then it really is a must read.

Throughout the book there are graphics of devils and guardian angels. Generally the little devils are telling you to take coding shortcuts, needlessly duplicate code to make changes quicker and don't even bother with testing. The angels are always saying that best practices are named so for a reason, but in the end the devil gets the best lines:

You need to hold meetings - lots of them. In fact, we're going to keep scheduling more meetings until we discover why no work is getting done.

Another part that made me laugh was describing how to attack debugging code by breaking the application components into more manageable parts. Not all that easy if the code is written as one huge chunk. This is described in the footnote as the "Big Ball of Mud" design anti-pattern. We use the same practice at work only I wouldn't describe it as "mud" exactly, same colour and consistency, just not "mud". It's only funny because it's so true.

Over the last few years I have become quite addicted to reading books on web design, programming languages and software development in general. I can't think why because in the past I was only concerned with anything but. When I returned home in the evening I certainly didn't want to start learning about another programming language.

The Pragmatic Programmer should really be required reading for anyone who is seriously looking at being a developer. You may not heed every piece of advice, you may not even agree with all of advice that is given but it will give you a better understanding of programming as a whole.

I enjoyed the book basically because I just sat there saying to myself, "That's what we should be doing at work!", "That's what I should be doing instead of what I'm doing now!". It's given me the enthusiasm to automate procedures, to make the computer work for me/us instead of the other way around. Of course I couldn't do this kind of thing without the Ruby language.

One thing happened on Friday while I was working. Now, I don't want to apportion blame on any particular hardware/software platform but I was deleting a file. I think the file was only about 3k in size and the little piece of paper was flying across the little progress window. Of course this is annoying as this takes at least 30 seconds to perform. I typically have 3 command windows open for development. Tip 21 in this book is Use the Power of Command Shells.

In my professional capacity, as a programmer of long standing, I've used a few languages: Pascal, Cobol, Silicon Office, Focus and currently Informix 4gl/Four J's and ASP.NET. Some I've liked using, some I've hated with passion. Visual Basic I tinkered with for a while at home and I just thought it was vile. Having a little bit of code embedded in a field on a tab of a property of a button just did not appeal to me at all. I am a little 'old-school' in that regard. I like to be able to open the program in a text editor and know that the reason it isn't working is in the file somewhere. And the fact that I hate using a mouse to edit programs with doesn't help.

Last December I decided to learn Ruby on Rails and bought the Agile Web Development with Rails book. I worked through the first hundred pages or so but felt that I need to know more about Ruby as a language before I moved onto Rails. Some people have programmed Rails without the need to learn Ruby but I've come from a procedural development background instead of an object orientated one.

This book is the definitive guide to the Ruby language and is sometimes call the PickAxe after the cover photo. It deals with all facets of Ruby from the initial tutorial, for people new to the language like me, to the comprehensive reference section at the back detailing all the methods, classes and modules.

I must admit that I struggled a little at first. Not because of a problem with the book more a problem with trying to get my rapidly ageing brain cells to think in new and different ways. Having just a couple of hours in the evening didn't exactly help either. But I did manage to read everything up to the reference section, so that I knew what the language was capable of. The more I read the more depressed I became. Realising that one line of code in Ruby could take me hours to code using 4gl at work just to perform the same task. You really are spoilt rotten by what the language can do.

It's a book that you will always have to hand because of the reference section at the back. As a programmer, there is nothing better than flicking through a user manual and finding something new about the language that you thought you knew so well. In that regard this book will be invaluable.