Today, I would like to address something that has been bothering me for a long time. A very long time.

Full disclosure: I am a consultant, and I help run a consulting firm. So what I’m about to say is going to sound self-serving, And, to some extent, it is. But that doesn’t change its validity or importance.

So. I write today about the nature of software engineering as a discipline. As a set of skills and experiences.

Software engineering is, in many ways, like no other profession. My focus today is on one specific aspect: professional development. Software engineering demands it. It is part of the fabric of our profession, and it happens daily. Hourly. Continously. Often without our even realizing it. We learn little things, like nuances of API’s and little language features that make us more productive, and big things, like object-orientation or dynamic languages and how to monkey-patch a framework class (carefully). And we learn significant but incremental things, like a new Ruby gem or a new framework for unit-testing Javascript code.

I’ve had countless talented, intelligent and driven software developers say to me, about code they’d written a year or so ago, “It works, but don’t look too close at the code – I’m not too proud of it. I wouldn’t do it that way again.” And my response is always the same. If you look at your code from a year ago and *don’t* cringe just a little, then you haven’t learned anything since then.

Carpenters have it easy. The hammer has been essentially the same, in form and function, for thousands of years. Tools we use in software development have a useful life span of a few years at best, before The Next Big Thing is upon us – at which point it’s time to crank up the learning engine once again.

Having said all that, here’s a little bit of advice to those of you who use consulting services.

Please don’t be among those who say “I don’t want your folks learning on my dime.”

Of course, you want to make sure that a consultancy you’re hiring is qualified to do the work you need done. You don’t want a bunch of people with only Visual Basic experience coming in to build your next Rails or iOS application. The team does need to be qualified to do the work.

But qualified absolutely does not mean that they’ll have prior experience in every technology, framework, or API that will be used on your project. That’s not how this profession works. We learn every day – because we have to.

What does this mean? It means, for example, that if you’re using ExtJS on a web project, you should have confidence in hiring someone with a solid background in web development with Javascript. We learn new frameworks all the time. It’s part of what we do.

It could also mean that if you’re hiring a team of four developers to build a Rails application, it’s okay if one of them is new to Rails, as long as that person is talented and has sufficient fundamentals (OO, another MVC framework, general Web experience) that will lessen the learning curve.

As a side note, if you manage a group of developers, think about the work they’re doing today, relative to what they were doing a year or two ago. Is it all that different? Are they working more efficiently, or producing better work? If not, perhaps they’re not learning quickly enough.

You see, in this business, in the long run, learning is always a net gain – for both the software engineer and the beneficiary of the software being created. You can’t afford *not* to have people “learning on your dime.”