Yet another book that I wish had been required reading when I was getting my diplomas.

It actually turned out to be a different book than I expected. I thought that it was going to describe ways of remembering class methods, design patterns and logic but it's more general purpose than that. The book details how the brain works, the R-mode and L-mode stuff, and how switching to a more abstract, physical way of problem solving can help you. For example, many times people that I've been working with have come back from the toilet and said, "I've just thought of a way around that problem!". Just the act of walking away and doing something else unblocks certain neural pathways. Before I had never understood the difference between mazes and labyrinths, and yes there is one. A maze is a puzzle to be solved. A labyrinth is a path that you walk around whilst thinking of a problem but only on a very shallow level. Just keep it in your thoughts but don't let it be the focus of your attention. One similar mind trick is if you are trying to remember something and it's just on the tip of your tongue, then recite something that you know, the names of the seven dwarves, and the answer with pop into your head.

There's a chapter on learning deliberately and using SMART (Specific, Measurable, Achievable, Relevant and Time-boxed) objectives, having a Pragmatic Investment Plan and reading with SQ3R (Survey, Question, Read, Recite and Review). That's certainly a chapter I'll be reviewing shortly as these reviews of technical books that I've read seem to be getting harder to write.

The Anne Lamott concept of the Shitty First Draft was mentioned and, until now, I always thought that it only applied to creative writing. The principle is that you don't strive for perfection straight away, that you rattle off something quick, you're not under pressure and you can just scrap it because you know that it's shitty. In the Ruby and Rails worlds I think that there is too much pressure to do something absolutely correct and right. If you're going to write a Rails application then you could spend months reading blog posts detailing the best practices for every eventuality. But isn't it better to just start and get something working even if your methods are more than 10 lines and you have a HTML tag in your controller. The same with tests, yes, tests are a brilliant idea but if you don't know how to do the actual coding how are you going to be able to write tests for it.

The book also covers screen set-ups (dual screen if you can get your boss to pay for it), virtual desktops, meditation (something that I've started, again) and how to focus and work free of distractions. I mention that because at work I have, on occasion, set my email client so that I have to click 'Get Mail' when I'm working on something that require concentration. But even then I get an IM or a phone call asking if I've seen the email. I'm sure my colleagues have their mail clients checking for new messages on five minute intervals or less. No wonder everything takes so long to complete.

With new programming languages, frameworks, databases and techniques being created and popularised every day this book should help you stay on top and be current. You can't just learn Cobol and expect a job for life.

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.

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.