I started working at RBI in August 2005 a few months after I finished University. My experience up to this point involved several years coding PHP in a very procedural way and a little bit of Java.

I was hired by RBI as a C# Web Developer and my work there involved working on several internal projects and looking after one of their websites.

At this stage I was still very much convinced that the art of software development lay in learning languages, so I used to spend all my time reading about C# and playing around with all the different APIs.

At this stage I was using Visual Studio without Resharper so I didn’t have the ease of Refactoring or moving code around that I now take for granted.

One of my colleagues took me under his wing and started teaching me how to write better code - separation of code across presentation/business/data layers was my first lesson. Suddenly it became so much easier to make changes! All the code I wrote was still in a non TDD way and after one episode where I created a bug in production I started to think that surely there was a better way to develop software.

Eventually my colleague suggested to me that if I really wanted to learn how to write software then the best place to do so was at ThoughtWorks.

I started working at ThoughtWorks in August 2006, hired through the TWU graduate program.

I thought I had a fairly good idea of how to write Object Oriented code but that theory was quickly disproved as I went through Object Boot Camp as part of my TWU training. The Single Responsibility principle was the overwhelming lesson learned as part of this. I also remember believing at this stage that it was all about Design Patterns.

I came back to the UK and did a couple of small projects where I first came across continuous integration and TDD before going onto my first big project.

I remember my first day on that project involved pairing with Darren Hobbs and being amazed at the speed with which he was able to move around the code using IntelliJ. It became clear to me that I had a long way to go.

Working on this project for the best part of the year I learned a lot, including how to write code in a Test Driven way, that everything you do in software is a trade off, but most importantly I learned how to master the IDE - if you can do this then you feel more confident and you can complete tasks much more quickly. This is always the advice I see given to new Graduates at ThoughtWorks - learn how to use your tools!

I moved onto my second project where I was immediately surprised at how much easier I found it to move around the code base than I had at the start of my first project.

We were designing a client side application so a big part of my learning here was around testing presentation logic. Jeremy Miller’s blog proved invaluable at this stage.

It was also the first time I came across the concept of Domain Driven Design - it was amazing how much easier it was to develop software when the developers were using the same language as the BA, QA and in fact the business. InfoQ’s cut down version of Eric Evans' famous book proved useful in helping me understand the concepts that I was seeing in our code base. I remember thinking at the time that I didn’t need to bother reading DDD as it was all covered in this version - I was wrong!

We had an very lightweight version of Agile being used on this project - we tried to have minimal process and do as many things as possible just when we needed them. It was almost Lean in nature although this was never explicit. It was interesting to me how easy and fun software development could be when it was done like this.

My third project was the first time that I got the opportunity to work with legacy code - i.e. code that hadn’t been unit tested. My early lessons on trade offs came back to me here as I realised that not writing unit tests is a trade off - you can choose to go more quickly initially by not writing them but eventually it comes back to haunt you.

I was working with Alexandre Martins on this project, and his enthusiasm for writing clean Object Orientated code gave me a new outlook on writing code. Working with him got me in the frame of mind of hating exposing the internals of classes and constantly looking for other ways to solve the problem when I was considering doing so.

Halvard Skogsrud’s knowledge around concurrency was another eye opener for me around how non functional requirements should have an impact on the way that software is designed. It also introduced me to the way that other languages such as Erlang handle concurrency - and behind this the idea of having as much of your code immutable as possible to avoid threading issues.

During a debate at a ThoughtWorks Geek Night another colleague brought up Alistair Cockburn’s Hexagonal Architecture, which was the first time that I had come across an Architectural Design Pattern. This is a useful technique when thinking about the design of systems at a higher level.

On my next project I did a lot of work around build and deployment which gave me the insight that developing software is about more than just the code. This was a lesson first taught to me by Chris Read a year before but it finally made sense to me.

A big part of this project was inter process communication between different components of the system which introduced me to the idea of event driven messaging. I immediately saw the benefits of this over the RPC style messaging I had seen previously.

I also had the opportunity to do some work with Ruby on Rails and in particular around the use of Active Resource. This introduced me to the idea of RESTful web services which feels like a much more natural way to communicate over the web than any of the other approaches I have come across.

The interesting thing for me is that I didn’t plan to gain any of these learnings, they came about as a natural progression from my interest in software development and from working on different projects with different people.

The biggest things I have learned since I started working in software development are that it is much more an art than a science and that there is no right or wrong, just trade offs that we should be aware of.

I still have a lot to learn but I thought it would be good to have a look at what I’ve learnt so far in the hope it can help others just starting out on their journey.

It would be interesting to hear about others' journeys and the similarities and differences you have experienced.