I recently came across this post which speaks about the desire of recruiters to put candidates into technology specific boxes when it comes to describing their experience.

I guess this desire is backed by humans' need to see the patterns and similarities in data and having someone who doesn’t quite fit into a generalised box makes it more difficult.

I have worked on projects in Java, C# and a bit of Ruby so I do agree with most of the points with regards to language specialisation and as Jay Fields points out it is actually beneficial to diversify your experience to improve yourself. I have certainly come across some interesting ways of doing things from my so far limited experience with Ruby.

The one part of the post I disagree with is the following:

While I still have a long way to go on my software development journey, looking at what I can do now compared with what I could do two years ago is not even a contest. It also doesn’t do justice to colleagues of mine who are orders of magnitude better than me, having constantly found ways to improve themselves over time.

I think perhaps the author was thinking more along the lines of '1 years experience repeated 9 times does not equal 10 years experience'. I think it’s fair to say that some of the best people I have had the chance to work with have not repeated this pattern.

If we are constantly looking for ways to close the gaps in our knowledge and looking for better ways to do things then we are certainly going to get better. On the other hand doing the same thing over and over again for several years probably won’t lead to a significant improvement.

Using different languages is certainly one way to improve but I don’t think we necessarily need to change the main language that we work with in order to gain all the benefits of doing so.

I have used both Ruby and Erlang, albeit briefly, and there were certainly lessons learned from my experiences that I can apply to my work in Java and C#. For example, using Ruby has shown me the value of convention over configuration and keeping code simple where possible, while my experienced with Erlang have shown me the benefit of having no state and have led me trying to keep my objects as immutable as possible.

As long as we reflect on our experiences and improve the way we work from as a result, having experience in several different languages is certainly beneficial.

There are some other ways that we can improve as well.

Gaining experience with projects at different stages is another way to sharpen the tools in our software development toolkit.

I have worked on projects which have been going for a couple of years, rewrites of existing systems and projects which are just starting out. The skills are similar but not exactly the same.

Early on we have the opportunity to shape the system and indeed the code and a lot of the work revolves around getting environments set up, configuring 3rd party APIs to work with our system, setting up the build etc.

Later on in projects the skills are around working out how to add new code without breaking existing functionality. This may involve working out how to test around legacy code, which is a skill unto itself.

Gaining experience in different roles within a team is another way to improve ourselves.

While I am not sure that this extends to everyone on a team trying out each of the other roles, I have certainly heard developers speaking of the benefit of working in a QA role for some period of time and personally I have spent time working primarily on build and deployment and seeing the world from that angle.

A colleague of mine on an earlier project always advocated the benefits of developers having to work in production support so that they could appreciate the value of putting useful logging into the code. I believe that this is something that is done at Amazon - you are expected to support your application in production, it doesn’t just get thrown over to production support.

I’m sure there are other types of experiences that we can gain, but the best people I’ve worked with have demonstrated a superior ability to solve problems, integrate systems, explain ideas to others, write code and so on.

It’s not the number of years, it’s what you do with them that makes the difference.