Wed 17 Oct 2007
In one of the greatest books ever written about software development, “The Mythical Man Month”, Fred Brooks refutes the premise that effort can be quantified in “man months”, the amount of work done by one person in one month. The central flaw is illustrated as follows: if a woman can have a baby in 9 months, then 9 women should be able to have a baby in 1 month. The core problem is that not all tasks can be reduced into parallel subtasks. Even when they can, breaking work into smaller units often adds overhead.
In a similar vein, I’d like to expose the myth of the so-called “year of experience”. In hiring, this is the basic unit used to measure ability. Look on almost any job posting and you will see years of experience required in something. Some postings use this metric sparingly, requiring a number of years of experience overall or in a single key technology, like 3 years of C++. Some postings carry this to such an extreme that you wonder if anyone could have that magical combination of experience. Thankfully, you don’t see this as much as you used to. Some ask for ridiculous amounts of experience in some areas. A few years back I even saw a posting for a Java position requiring more years of experience than Java had been around!
What companies need is someone with a certain level of expertise. But how do you quantify expertise, particularly in technical fields with broad areas of knowledge? That’s where the mythical year of experience comes in. It may not be accurate, but it is quantifiable and easily verified from a candidate’s work history.
The reliance on Human Resource departments may also explain the popularity of using years of experience, particularly in technical domains. In general, HR representatives aren’t engineers. They don’t truly understand what we do for a living and are unable to tell a good engineer from a bad one. But it’s their job to screen candidates and provide suitable ones to hiring managers. So some criterion must be used to filter out unsuitable candidates.
Experience != Expertise
There is an assumption that a certain amount of experience will produce the desired expertise. However, experience does not produce expertise! Experience is important in developing expertise, but expertise requires that the person has the will and ability to extend their knowledge and refine their abilities. Without this, experience just reinforces your current methods.
On one project, I worked with a person who was responsible for doing the builds, who had been working on this project for 5 years. In that period, the approach used hadn’t changed significantly since the first year. I’m sure he claims 5 years of experience for that work, but it really should be considered 1 year of experience with 4 years of repetition. I’m not saying that the build process needed any changes or improvements. My point is that repeating the same activity over and over should not count as experience. It certainly does nothing to further your expertise.
By focusing on years of experience rather than needed expertise, you may even rule out better candidates. Say that a position has a stated requirement of 3 years of experience in C++. The best programmers learn new languages and technologies quickly. Indeed, a great programmer will have a better understanding of a new language after six months than the average programmer would have after three years!
Most technologies don’t take several years to master. When learning a new technology, the early part of the learning curve is the most intense. By the end of the first year, most people are in the incremental learning cycle where they are picking up knowledge very slowly. From my observations, there is little difference between the knowledge a person has after 1 year of using a technology and after using it for 3 years–unless something motivates them to learn more. Even great programmers are in the incremental learning phase by the end of the first year, but they have attained a higher level of understanding in that period than many others will gain in a lifetime.
In my career, I’ve interviewed many C++ programmer candidates. Most have done little to extend their knowledge past their initial training, often a training class that lasted a week or two. Most have never read any books on the language, other than the book they used to initially learn the language. It’s rare for me to interview programmers who have read even a single book on Object-Oriented Programming. For a person like that, 3 years of experience will not lead to much expertise—unless their project provides an exceptional opportunity to learn from more knowledgeable developers.
The rate at which someone learns a new technology is one of the most important factors in recognizing top programmers. Even if you could write the perfect job description and pin down the exact combination of knowledge and abilities for the current project, that mixture will be out of date when the next project comes along. It’s not uncommon for technologies to change even during the scope of a single project. When it does, what good was that carefully crafted combination of skills?
Yes, Experience Does Matter
This doesn’t mean that experience is unimportant. Experience allows us to learn from mistakes. It provides opportunities for problem solving. Just as important as the knowledge of how to do something is your trouble-shooting ability when things go wrong. This knowledge is often best gained through experience.
Even so, you can’t measure this experience solely in terms of time. It has more to do with the number of lines of code you’ve written and the number of unique technical challenges you have faced than the number of years you’ve done something. Given two programmers with 5 years of experience, the one who has written hundreds of thousands of lines of code will generally be more experienced than the one who has written tens of thousands. Likewise, a programmer who has worked on several projects in that timeframe will likely be more experienced than one who has worked on the same project.
When writing job descriptions, I use years of experience only for the overall number of years as a programmer. This is an effort to factor in the lessons learned from experience. Even then, I’m always watching out for the highly talented person who has come by their knowledge and experience faster than their peers.
What Does This Mean for Me?
In your career, don’t assume that years of experience is enough. Push the learning curve as hard as you can. When you are learning a new technology, seek out the books or other materials in that area that can give you knowledge that would take years to learn on your own (if ever). Use the work you do each day to drive your learning. For example, if you’re writing a new C++ class and you’re unsure whether to overload the copy constructor, use that as a reason to really learn the best approach. Don’t settle for mediocre knowledge.
Having pushed the learning curve, don’t be intimidated if the years of experience don’t match your background when you apply for a position. Stress to the recruiter that you have the knowledge that someone with the specified years of experience would have. Be sure you can back that up in interviews, though. Savvy hiring managers will quickly spot a pretender.