Writing software is hard, particularly when the schedules keep programmers “nose to the grindstone”; every so often, it's important to take a breather and look around the world and discover what we can find - ironically, what we find can often help us write software better.

What, exactly, constitutes “years of experience” and why do people keep asking about them?

It's the staple of the software developer's humor mill: the software developer job request with the ridiculous requirements that couldn't possibly be met by any creature, living or dead. I just recently saw one myself, coming across a mailing list here in Seattle dedicated to the local startup scene; I won't quote it in its entirety, in order to protect the innocent and the guilty, but the core of it read something like this:

Now, if you stop and “do the math” for a moment, for a developer to claim to have 10+ years of experience in the .NET stack, they would have had to have been programming using C# prior to its 1.0 release - as I write this, it is the tail end of 2010, and it was only in October of 2000 that Microsoft announced .NET (at the time, going by a completely different name-free shoutout in the next article to the first reader who can send me the name via e-mail) to the world. So said developer would, quite literally, have to have been working at Microsoft on the project-that-nobody-can-talk-about (known as the “P7” project, supposedly because seven external groups were involved in writing languages for the new platform, including Bertrand Meyer's Eiffel and Fujitsu's COBOL, as I recall) in order to qualify for this project.

And to what end?

Matchmaker, Matchmaker ...

It is a well-known truism of our industry that, unfortunately, nobody knows what the hell we are talking about. It's true - one of the reasons why software geeks in general are so sidelined away from the rest of society is because we deal with things that nobody else in the world can possibly understand, partly because what we deal with on a daily basis simply doesn't exist.

Don't believe me? Please point to the operating system in the room with you. Go ahead. I'll wait.

Or, better yet, open up the computer and show me the running processes and threads. If we get a small enough microscope, can we see the objects?

Any other job in the world (with very few exceptions), the practitioner can point to what they work with - the mechanic to the car or the engine, the doctor to the body, the airline flight attendant to the people on the plane, the football player to the game on TV. Everybody else can point to something to which people outside of that industry can relate.

People come up to us, on the other hand, at parties or other social engagements, and ask us, “So what do you do?” How do we respond?

Is it any wonder that Ward Cunningham describes one of the biggest benefits of Pair Programming as being the opportunity to socialize with somebody who actually understands you?

The Grid

As I write this, the movie “TRON: LEGACY” is eating up the box office, partly because of the “geek love” factor - geeks like me remember the first movie from the early 80s, with the neon characters and cool light bikes and deadly Frisbees, and most of all, how the main character, a sit-at-the-desk-and-write-code hacker (like us) managed to become the hero and save the universe (or at least the computer) and defeat the evil management type and his alter-ego within the computer, the Master Control Program. C'mon, what's not to love there?

Just a week before writing this, I bought the soundtrack for the movie as a prelude to watching it sometime over the holiday vacation. For the music lover out there, it's great coding music. By the way - kudos to Daft Punk. One of the pieces, entitled “The Grid,” opens with Flynn (Jeff Bridges' character, the hero from the original), talking over the music about how he “tried to picture clusters of information as they moved through the computer. What did they look like? Ships, motorcycles, were the circuits like freeways? I kept dreaming of a world I thought I'd never see. And then… one day… I got in!”

With all due respect to Disney… WTF?

In all the years I've been writing code, the only ships or motorcycles I've ever run across were as examples of class hierarchies inheriting from an abstract base class Vehicle, and the only places they "freeway"ed to was the relational database and back again. This is our �ber-hacker hero, picturing ships and motorcycles and essentially a digital-yet-literal translation of the real world? I felt vaguely cheated.

The Job

This is the essence of the problem - what we work with, nobody else can understand, because it requires a visualization of the abstract based on abstractions that in turn are based on abstractions. The only things moving around through the system are ones and zeroes, and let's be honest, that version of the movie would be pretty boring.

Compounded with this, then, is a realization that if “normals” can't see what we work with or how we work with it, then it also stands to reason that they can't tell whether what we're doing is brilliant or deranged. Is the program we're writing something that will stand the test of time, or collapse the moment a second user tries to use it?

(Cue the infamous joke: "If buildings were built the way programmers wrote programs, the first woodpecker to come along would have crushed all of civilization.")

So how does a mild-mannered recruiter find somebody who can build programs that will stand against the first woodpecker?

The recruiter's job, remember, is to spend time hunting down elusive quarry: programmers who can do the job they need to do, on time, under budget, with a minimum of ego and ideally within a reasonable salary band. We'll ignore the nits hovering around what “reasonable” salary is or whether the programmer is responsible for the myriad project failures in the industry, at least for now - let's just assume a recruiter is asked to help out on a middle-of-the-road job looking for a middle-of-the-road developer.

They do this, by the way, mostly so that you, as a member of the development team to whom that candidate could be assigned, don't have to wade through piles of resumes labeled with “Microsoft Access expert” when you're looking for a SQL Server DBA.

How, in the name of all that we programmers hold holy, is a non-technical person supposed to find a good programmer, particularly in a scalable fashion? It's not reasonable to expect that a recruiter will be able to spend an hour on the phone with the thousands (or even only hundreds, which in this economy isn't likely) of people that apply for a job. So what qualities can a recruiter ask for, or look for, typically on a resume, to determine whether this candidate is a reasonable person to bring in for an interview?

How the interview will determine whether this person is a reasonable person to hire is a wholly different subject, and not one to consider here, by the way - that's another discussion worth having, but on another day.

Developers who've been around the industry for more than a few minutes already know the answer to how recruiters typically measure our skills: by the aforementioned “years of experience.” It's an easy metric to suss out from a resume: if they started working in 1995, then just a little math tells us that they have 15 years of experience, which qualifies them as a “senior” developer. Maybe even an “architect”.

Is this reasonable?

The Experience

In many ways, the recruiter's use of “years experience” as a metric stems from the basic presumption that “the more we do something, the better we get at it.” For a lot of industries, that clearly holds: do you want to receive your heart transplant from the med student who just graduated from medical school, or from the grizzled old doctor who's been doing these for 30 years?

Other industries, though, clearly don't hold experience in quite that same light - athletics, for example, frequently sees the old grizzled veteran forced to give way to the hot, young talent, not because the hot young talent knows more, but simply because the old grizzled veteran is old. Old means slower, more prone to injury, and therefore less effective.

And our industry?

It's tempting to suggest that being an almost 100% mentally-based industry, we fall into the former camp, but how many programmers here would be willing to hire a 30-year-old veteran who's been doing nothing but mainframe development the whole time? Is that somebody who can bring mad skills to the team that make the project go forward quicker/smoother/more effectively?

Or is he going to be the one we're training as we go?

At the same time, though, hot young programmer talent coming out of college is something of an oxymoron: it's widely assumed that anybody coming straight out of college - regardless of the college, by the way - has a fairly steep training curve in front of them.

What if we partition the experience up somehow? What if we say you have to have “N years experience in X technology?” Does that help?

On the surface of it, maybe yes, maybe no - does a developer with 10 years of experience in .NET strike you as a senior developer? What if those 10 years have been all in Visual Studio 2002 maintaining the same WinForms-based desktop app? Is he the senior developer you want on your ASP.NET MVC project?

The Programmer

Given all of this, what's the industry to do? To be honest, I have no idea what better metric to use. (Well, that's not entirely true-I have ideas, but I seriously doubt the industry is going to listen to me on this one.)

One thing every developer should take away from this is that the notion of “experience” matters differently to different people, and that developers need to have thought about where they sit on the topic. Do you want to be a developer with 20 years of experience on one project, or a developer with 20 years of experience on 40 projects? Either case is, admittedly, at the extreme ends of the spectrum and thus hardly a likely scenario. But the developer aspiring to a new job will likely fall to one end of that spectrum than another, and needs to be able to answer “Why” to the interviewer when that question comes up. Do you value the wide spectrum of problems and solutions that those 40 projects gave you? Or do you value more the insights into versioning that the one project over 20 years gave you? The more clearly the candidate can express this in the interview - and possibly on the resume itself - the more likely it will be simply accepted instead of questioned or serve as cause for concern.

For some, the more critical question is, simply, how does the developer interested in getting hired get past this particular HR blockade? Obviously, the developer who's been writing .NET code since 2001 will be able to simply say, “10 years .NET experience” and call it good (if perhaps potentially deceptive). But what about the developer who's been committing patches to NHibernate, writing ASP.NET MVC web apps for local charities and hooking up RESTful services for his dad's gun shop website, but only graduated this year?

Remembering that the HR blockade is essentially just a filtering gateway to go through, and if the programmer in question feels comfortable doing it, young hot talent might take the position that they have the equivalent skills of somebody many years their senior, and write it as such:

Obviously, the candidate who does this has to be able to back their assertion with a solid interview, or risk being physically hurled from the office. But until the industry finds a better way, gaming the system like this will continue to have to be a “way in.”

As to what we should be measuring instead, ah, well, that's a subject we'll have to pick up at a later date.

(Thanks go to Roy Leban, Bruce Leban, Adam Phillabaum, and other members of the Seattle Tech Startup list for the subject and the discussion.)