It's hard to find good developers. And it's worse than useless to filter candidates by "experience" as included on a resume. Statements like "10 years Java experience" or "15 years SQL experience" are meaningless. The problem is that you can't sum up real experience in a single concise number, and if you could it wouldn't be measured in years.

We could try to come up with a formula, but any attempt to do so makes it clear that "Software Developer" encompasses a very wide variety of actual skills. What I'd really like to see on a resume, or in addition to a resume, is a real list summarizing all the things you've actually done, and the lessons you learned while doing them. This includes all of the following…

1. List each book you've read that seems pertinent to software development, and summarize what you learned. Books are your number one resource for accumulating some subset of the experience of others. If you're not the type to read a book, then I hope you're able to make up for it in other ways. It's not likely though. You might hope to get the same benefit from blogs, but the best of them are just going to restate something that's been said better and more thoroughly in a book.
2. List each project you have worked on, no matter how small, and what you learned from each one. There's a lot to be learned from projects big and small. I've personally built full products by myself from scratch, and worked on a variety of teams ranging in size from 2 to 20 developers. I've even spent some time working on one of hundreds of small teams working together on a truly massive project with something like 10,000 developers spread throughout the country. I've learned different lessons from each of these experiences, and I feel it adds up to more than "14 years experience". Many people in our industry get sucked into giant corporations, where they work on some tiny piece of a large maintenance-mode project for years at a time. They tend to slow down over time, cranking out a new SQL report once every month or two, and gradually falling further behind. I've nearly been trapped in similar situations myself, so I know you have to be ever-diligent to avoid it.
3. List the various roles you've played in the software development process, and what you learned from each experience. Have you ever lead a team of people? Have you taken a back seat to another tech lead? Have you ever designed a real software product by yourself? Have you written documentation, or even a book? Have you taught courses, mentored junior developers, pair-programmed, designed web pages, designed a non-web GUI, played the part of a non-technical manager, or any of dozens of other roles that developers may experience in their career? What did you learn? Did you have good mentors in your early years, or did you have to learn everything the hard way?
4. List all the type of processes and tools you've experienced in real professional development, not counting hobbies you've tinkered with at home (Unless you built something that people actually use.) I've built both GUI and server-side applications, both commercial software products and internal applications, used 8 different languages on non-trivial projects, become proficient in 6 different IDE/Editors, etc. I've found each of these experiences valuable.
5. List your major successes and failures. There are always some high points and low points that stand out from the rest. When you look back on projects that were less successful than you'd hoped, then take the time to think hard about what really went wrong, and what you personally could have done better. In your internal dialogue, accept full responsibility for any problems, and don't lay the blame on incompetent management, lazy coworkers, indecisive customers, or other distractions. Try instead to imagine what you could have done to make the project a perfect success. Maybe you should have tried harder to understand the customer requirements instead of trusting a Systems Analyst. Maybe you should have found a way to work around management incompetence? Maybe you should have devoted more time to mentoring junior developers instead of forcing them through the trial-by-fire that you suffered through? Or maybe you shouldn't have coddled those junior developers, and let them learn a few things the hard way? Then again maybe you yourself are falling short in some ways. Do you understand the business point of view? Do you over-engineer, under-engineer, fail to test, test too much, write sloppy code, spend too little time designing before coding, or fail in any of thousands of other ways?

The above list probably does give us a fairly good measure of experience. If you can work through each of the above items completely in a fairly terse writing style and finish in less than a month, then you're probably not very experienced. Looking at this list, I can't even estimate how long it would take me to thoroughly explore the 5 items.

I'm not sure, but it might be worth working through the exercise for yourself. Just don't expect anyone else to read it.

My next post, …

Experience Isn't Everything