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.
Posted in 
Funny enough, yesterday I was complaining with a friend about all those “they all look the same” job offers: minimum years in .
I said: “What do they think we are? Ham, whisky or what? How do years of experience match with expertise?”.
Good post, I will probably append the link to my future cover letters
Ah, so this is where year inflation comes from. The hire with “3 years experience” is an average programmer with, say, with 2 months of ‘normalized’ experience. And then they turn out to be pretty incompetent, so clearly the next hire needs to have 4 years experience…
As an extreme example of this inflation, I once saw a position which asked for 1 year experience… for an _intern_.
You’re absolutely right. Years of experience does not equal skill. This is not only true in software, but in most other industries. A carpenter that’s still using the exact same techniques from 20 years ago is no better than someone who’s just started. Both don’t know how to do it to the new appropriate standards.
I truly believe that experience is good, but you have to continually push your knowledge during that time. For me a great indicator is what you’ve read. Although not entirely accurate, I find it’s a better indicator of skill than years of experience.
There are some classic books in software development such as The Mythical Man Month that should be read by all developers. Sure you may skip a few, or not even know about them all, but if I give you a list of the top 20-50 software development related books, you should have read at least a few. If you can identify any, well…
Funny, I just wrote the same thing yesterday at What Is Experience? (Or Why EJBs Are Like Lobsters)
At a job interview last week this syndrome was described to me as the n by 1 problem. e.g. they had a developer who had 5 years of experience, but really had done the same one year of experience 5 times, so he was a 5 by 1.
That, and this blog post, are an excellent observations – having interviewed hundreds of developers in my time, I’m often sadly disapointed at how little they seem to know despite their time in the trade.
Years in experience in a certain environment / language are not very indicative of programming prowess but the total time of your life spent learning new things is. As the old saying goes “Old programmers are not smarter than the young ones, they just made the same stupid mistakes before and know the way out”
As someone who loves to learn and evaluates job opportunities mainly by the knowledge that will be gained from them, nothing can match doing short projects in technologies you have yet to mastered. I worked as a freelancer for 4 years and it has been the most productive 4 years of my life CS learning wise. Doing the same thing in different languages will teach you very little, but there are so many sub fields in CS that even just tasting every one of them in a real world environment is priceless.
Doing Artificial Intelligence, Image recognition, data mining, kernels, device drivers, RT, Servers.
Each one of these, beside being an entire world that can occupy your entire professional life, can also give you valuable insights and perspective that will affect any piece of code you right from that day on, even the simplest web script…
And can we please get rid of the LOC metrics? I can’t believe you buy that. LOC are the tax we pay to have functional maintainable software, the less of them we create without harming the functionality and maintainability the better we are off.
Thanks, everyone, for the comments. Codist did beat me to the punch, but I did write this a couple weeks ago. I was just waiting for my turn in the queue.
Marcus, don’t get wrapped around the axel on the LOC thing. My point isn’t that writing more code provides a better solution. It’s that the number of lines of code you’ve written is a far better metric for experience than time. Assuming an acceptly succinct programming style, you will learn more and have more opportunity for troubleshooting by writing more code–not more code to tackle a single problem but more code to tackle more problems.
And, yes, I do think LOC metrics matter. And apparently, so do you. Your point is that a solution is better if it involves fewer lines of code. Well how do you know that someone has achieved this if you don’t measure it? Just as cyclists measure heart rate, cadence, and wattage to analyze their performance, programmers should measure all sorts of values to analyze theirs. None of those values directly translate into victory, so you always have to interpret them. But they do give you insights into performance.
If you had two programmers and one consistently wrote twice as many LOCs every month, wouldn’t you be curious why? It doesn’t automatically mean the one with the higher LOC count is better, but it gives you a starting point to investigate. Perhaps he is writing more verbose code. Perhaps his tasks are simpler and he simply writes more of the same boilerplate code over and over. Or maybe he truly is more productive.
I guess that’s a topic for another blog, though. 8^)
I’d say LOC should be taken with a grain of salt and used along with a number of other productivity metrics.
For example, there have been a number of times I’ve written 50 or 100 lines to do something. After having done so, the light dawns and I can reduce it down to an elegant 10 or 15 lines.
This illustrates a number of caveats. First is that, in some cases, the person who writes an order of magnitude less code, might be writing better, maintainable code.
This also indicates that someone writing more LOC per year is not necessarily better than someone writing fewer LOC per year.
How does one develop a metric for the thinking and puttering time? Time spent to come up with an elegant, easy, maintainable solution? Perhaps something like LOC/feature would be better. And, yes, I know, the question becomes one of defining quantifiable features,… etc… but is something to think about.
LOC should be taken with a massive grain of salt.
Not only does it tell little about productivity outside the context of the work it is measuring, but it tells nothing if the people you’re comparing have disparate responsibilities.
Even if 2 people are both nominally “programmers”, one may spend more time debugging existing code or assisting QA people or customers than the other, or be engaged in design work as well.
He’ll produce less LOCs than the guy happily chugging away at some new and rather simple project for 40 hours a week minus toilet breaks plus overtime.
But he’s no less productive.
There are weeks I produce maybe 10 lines of code in a day (on average), other weeks I may produce hundreds or more a day on average (and that’s without code generators).
Yet my productivity doesn’t swing by orders of magnitude over the same period, it’s just that my activities are rather diverse.
On a similar tone there’s an old warstory I lived through about a decade ago.
Our project teams all had KLOC targets for each release.
On one maintenance release our job had included a major cleanup of our codebase as well as some minor new features and bugfixes. We also had to do a lot of documentation work to get rid of a backlog stretching several years by that time (don’t ask, review cycles took that long there).
As a result we ended that release with a KLOC count of -20.000 lines of code for the 4 of us, with a target of +50.000.
We got an official reprimand from the company for that, which took the personal intervention of the project manager to get rid of (he’d known and approved our plans).
We’d actually created 30.000 lines of code, plus several hundred pages of documentation, but as we scrapped another 50.000 lines the end result was negative.
Those 50.000 lines less code to maintain meant a lot less brittle code, and helped no small bit getting our stuff Y2K compliant and ready for the Euro.
As to years of experience and the ridiculous things you sometimes see:
Back in about May ‘99 I saw a job ad listing a hard requirement for 10 years of Windows 2000 administration. Windows 2000 had been released the month before.
When learning a new technology, the early part of the learning curve is the most intense.Technology controls every thing.
You’re absolutely right..
I too will perhaps like to include the url to this post in my Profile like Riccardo
@Scott
the only thing is you are emphasizing too much on Books.
I can’t remember when was the last time I touched a Book. I learn by either real life Problem Solving or by reading stuffs online…
I get frustrated when People ask me How much experience I’ve got.
Sometimes I will respond
“I am 28 years old and I think I’ve learned something everyday so I’ve got 28 years of Experience.”
Or if I am too pissed up at the moment I will simply say
“I don’t like to judge one’s capability or at least my capability in terms of years of experience…”
Haah…
The whole Industry is Confused I guess..
and aah..
This was funny..
Hi Bijay,
Yeah, I do like books a lot. I use web resources too, but it’s hard to replace a well written book. Books provide a greater depth and breadth on a topic than the typical web article can.
In most areas of knowledge, I think there is a list of seminal writings that experts should be familiar with. Certainly, there is a great deal to be learned by doing, but reading, particularly while applying what you read, can dramatically shorten the learning curve. It could have taken me decades to discover of all of the valuable lessons I’ve learned from Scott Meyers “Effective C++” and “More Effective C++”.
Really, as long as you are reading I think you’ve got it covered. The main point is to learn from others who have been there before you. Then you are in a position to knowledgeably invent your own patterns or chart or new course.
[...] experience follows a business agenda, and for the most part that implies repetition of the same experience after a while. To say one has worked 4 years with C++ does not imply she has [...]