Richard Patching

A Craftsman’s Legacy

by: admin

I’ve been thinking a lot recently about legacies, the things that we leave behind, things that out live us. The very nature of our business doesn’t leave much room for lasting legacies, sure you have legacy code, but that in itself often carry’s negative connotations. Rarely do we celebrate our old code, the fact that those cringe worthy snippets are actually serving as a reminder of how far we have come. Ok, so you previously wrote huge controllers, large complicated methods, overused design patterns and violated every best practice going. But now you know better, you’re well versed in the ‘Fat Models, Skinny Controller’ mantra, you refactor to design patterns when necessary and you abstract those large methods. Legacy code is great. But thats not the point of this post.

I want to explore our lasting legacy beyond code. Unfortunately every line of code we write will be refactored, replaced and removed at some point. The great software we write today will become obsolete tomorrow, replaced by some better, faster, feature-rich app. Or it loses it’s relevance in a sector that changes so rapidly. For me this is worrying, what will I leave behind? Is my code destined to live on only in the archives of the internet, left on a few old hard-drives, eventually no longer able to run or compile. The answer is probably yes. I don’t believe my lasting legacy as a software developer (craftsman) lies in code, but in the people I will meet, my future apprentices. Our only tangible lasting legacy is what we impart into other people. They will watch us, question us, learn from us. Some of our habits will become their habits, our tools will become there tools. If we mentor them right, they will go on to impart into other people and so our legacy continues.

I have only recently embarked on my apprenticeship and already learning a huge amount. The time spent pair programming, chatting and socialising with Chris is already shaping the craftsman I will become. James and I will no doubt mentor others in the future, the things we have learnt from Chris as well as our own experiences being passed on to our apprentices. Our legacies living on…

Posted on: April 13th, 2010 by: admin In Categories: apprenticeship, ramblings, work-life | 1 Comment »

Last one of 2009

by: admin

Today is my last working day of 2009, this last year has flown by! I did briefly contemplate writing a blog about the things that I have learned this year, but soon realised that would be crazy, there has been so much. This time last year I had been a Ruby developer for 3 months, on top of that I was learning Rails, TDD/BDD, Agile etc. I also distinctly remember what the last week (of 2008) in the office was like, I got to see first hand what happens when the technology that should be working for you, starts to work against you. The technology we were using to store our data was falling over frequently, the delivery date for the iteration was looming and important decisions had to be made. Stick with it and try and make it work? or migrate over to something a little more tried and tested? We went with the latter, because of good design decisions and practices.

That week I learned the value of abstraction, had we had tied our data model code too closely with a certain technology we would have been in trouble. Despite being a bit of an inconvenience the move over to the other technology was relatively easy. The other lesson I learned was to take the last week of the year off So that’s what I’m doing.

Bringing everything back up to the present, this week has been good all-in-all. Monday afternoon was the time that I ran through my first apprenticeship task with disappointing results. We were asked to do a Binary Search code kata in Ruby and RSpec. The kata was successful in that the tests I wrote lead me to a solution, the way in which I approached the tests was wrong… very wrong. I approached the problem how I would with any new model I was creating, I started to spec how I wanted the code to behave. This challenge differed slightly from your day-to-day client project, in that you are trying to drive the development of an already-designed algorithm. All I really needed to do was to drive an initial set of assertions and then develop a suite of tests to cover the other edge cases. There was no real need to test every line of code. By doing so you only tie yourself down to your implementation. What if you were asked to implement the algorithm using a different approach, you would have to throw away all your code and most of your tests. Waste. If I had written a suite of tests that covered exactly what the outcome should be, I would only have to re-write my code, using the same tests to confirm when it was complete (all passing). Very important lesson learned, thanks James and Chris.

So i’m going to spend some time running through my kata again until I get it nailed. It has also inspired me to spend some time learning how other people do TDD. I have realised over the last year how different everybody approaches TDD, it is very rare to find two people who completely agree on how best to write tests. Everybody has their own styles and practices, and thats a good thing, as long as the code is tested well. Over time i’m sure i’ll develop my own style and practices, but always remaining open to change.

Have a great Christmas and New Year! See you in 2010!

Posted on: December 24th, 2009 by: admin In Categories: apprenticeship, code kata, work-life | 1 Comment »

The Apprentice (minus Alan Sugar)

by: admin

I had the pleasure recently of reading ‘Structure and Interpretation of Computer Programs’, I have by no means finished it yet, but there was something on the very first page which really leapt out at me. The authors Gerald Sussman and Hal Abelson describe how grateful they are to have learned software development from the feet of masters such as Richard Greenblatt and Bill Gosper. Two particular heroes of mine. I started to think about the vibrant Open Source community and the Internet, how easy it is for us all communicate, yet how lonely software development is. We all work together in our remote locations, writing new features and submitting patches and very rarely communicate on a one-to-one level.

So who are my mentors? When I look back at the end of my long journey, who will I say are the people who mentored me? The masters from whom I humbled myself and for a period of time became their apprentice. In the 5 years that I have been on this journey of software development, I have been profoundly affected by the work and attitude of one man, Chris Parsons. Having left University thinking I had a pretty good grasp of Computer Science and modern development methodologies, I quickly learned that I knew very little. It was Chris who introduced me to Agile, BDD, XP, Ruby and the framework Rails. It was Chris who spent the first three months of my employment taking me from a naive developer with zero confidence, to a competent developer who knew that by using certain methodologies and best practices could write almost anything. The only limitation would be my own knowledge of programming languages.

On the 25th November 2009 he officially became my mentor. When he approached me regarding the position, it was a no-brainer, I accepted after a quick call to my wife Today I am really excited/apprehensive about the road that lay ahead. I know that long transition from apprentice to journeyman will not be easy. I’m expecting to stretched to my limits, but I know I have the passion and self-determination to make it.

I’ll be blogging here about my successes, failures and the projects that I work on. I’m looking forward to sharing my journey here, so check back from time-to-time

Posted on: November 28th, 2009 by: admin In Categories: apprenticeship | No Comments »