How useful would it be for a recruiter?
In martial arts there are a minimum number of trainings, not years of practicing, to be evaluated for a higher level. I saw some exceptions but there are rare.
In software, maybe this would be valuable to express experience in particular technologies such as OO, OR/Mappers or specific DBMS.
I once worked with a guy.
His boss told me: "He thinks he has 7 years experience. He does not. He has 1 years experience, 7 times."
The subtle difference is in not learning / growing / thinking more.
There's a big difference between a Pilot and a programmer. A Pilot has to know and memorise procedures, and be able to think in a crisis. A Programmer has to think through complex issues and create new things out of nothing, and do this for between about 2 and 6 hours a day.
You can improve your ability to think by actually doing it, but to claim that "time on job" in a creative business is equivalent to a skill set is a bit of a stretch.
Once you clear 10,000 hours it's all relative
From Malcolm Gladwell's Outliers, it can be shown that 10,000 hours of continuous active learning (about 10 years at 20 hours per week) is required to become an expert in a particular skill.
I'd say that the rule is transportable to programming, even allowing for changes in frameworks and techniques. I'm thinking exposure to design patterns, methodologies and so on.
If you then follow the Dreyfus model of skill acquisition then it seems that the following may hold true (I'm just filling in numbers as I feel - there's no citation):
So to enable you to filter your candidates, perhaps apply these values to each of the levels of experience you require in your top skills (allowing for general overlap due to exposure, e.g. a Spring expert will surely have competent XML).
Now, comes the tricky part - just how are you going to prove that they're telling the truth? Perhaps it's time to break out "Fizz Buzz" and "Guess a number".
I'd rather say it measures what cannot be expected.
Someone who has worked in the field for 20 years may or may not know a lot of things, but one who has only worked for years or months is guaranteed not to know these things.
You can only verify what is actually known by probing or testing them.
I think that, past a certain point to establish a minimum level of competence, the amount of time one has been programming isn't all that meaningful. I would judge a programmers experience on the projects they've worked on and what they brought to those, not an arbitrary number that is practically impossible to verify.
I think that I already posted this (Teach yourself programming in 10 years) somewhere but you should check it out. This article is about that "magical" 10.000 hours and about the efficiency of learning.
How many hours of painting does it take to become a professional painter?
How many trainings does it take to become a professional musician?
Programming too is a creative design activity, which is why most metrics are literally useless.
The only thing that can be said, is that with time you become better. Whether any time in the world will suffice for you to become great, is unknown. One can only look at you at any given time and decide whether you're good or not.
Programming languages change. Tools change. Paradigmas change. That limits the value of experience after some years.
That said, most programmers work fulltime, so the number of years is more or less directly proportional to the number of hours spent coding.
I think you could compare it as a metric to lines of codes (of a program).
You can't assume too much about the quality of the code (experience in your case) but you can make some assumption about it.
Ie you can make some assumption about a guys with 6000h experience vs a 100h even knowing that you know that there is difference in the quality of the experience of the two (you cannot know or estimate it but when comparing magnitude difference, details start to matter less).
You couldn't use it to tell much about say a 6000h vs a 6500h though or even 4000h to 6000h, say. (I'm using arbitrary number here).
I'm not even sure if the number of hours a pilot logs is all that informative either.
I mean, someone that flies from Charlotte, NC to Portland Oregon and back (alternating days) will have a lot more logged hours than someone that flies 4 times a day from JFK to Logan. But, I would guess that someone that makes 4 flights a day will gain 4x as much experience as someone that makes one flight a day over a longer distance. Further, the NY to Boston flight will be over a much more congested space at busier airports, resulting in much more experience in tricky situations compared to the less crowded Charlotte, Portland, and big sky airspaces they would be largely flying through.
Likewise, for programmers, i can work 10,000 hours aligning textboxes on a windows form, or I can spend 10,000 doing a variety of tasks with varying levels of complexity.
Hours mean nothing, nor do years.. you can only look at the accomplishments. The only value I see is that someone with 10,000 hours would certainly adequate, or they wouldn't have been able to log that many hours. But number of hours cannot tell you if they're an expert or not.
For this to really work, programmers would need to maintain a logbook.
Pilots keep meticulous logs of their time in flight and simulation, and count their time 'in type' - 2,000 hours of flying a 747 doesn't immediately qualify you for the A380.
The martial arts training programmes also require some logging (at least, my old Judo training did).
There also needs to be some mechanism to audit the logs - commercial pilots are regularly placed in simulators and tested. Martial artists have to be examined (or compete - which is a harsher judge) in order to level up.
So, for time-logging for developers, we'd need to be able to categorise our time (I have thousands of hours in PHP5, several hundred each in C++ and few others), and be regularly audited (as has been mentioned already, dragging and dropping form elements around in Qt Creator doesn't make you a C++ guru).
All this is a far too complicated for not much gain - so I side with everyone else that says that programmers should be rated on knowledge and achievements that they can point to.
I began very basic programming in third grade and have kept up with it for about eleven years now. This means that I already probably had a thousand hours logged by middle school, but a thousand hours of experience back then and a thousand hours now result in totally different levels of learning.
Knowledge and learning seem to follow an exponential curve-- I am able to more easily pick up programming concepts and learn new languages (which helps in an attempt to be language agnostic) than I was eleven years ago. Five years of experience is not half of ten years of experience. Giving a more personal answer to the question "How long have you been programming?" seems to be optimal.
I would not express it in hours; - I would express it in lifetime lines of code or years spent coding.
