Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If you are a Senior developer with say 8+ years experience, how much time spent doing programming is reasonable for competency on average? Specifically working with some library or framework associated with the core language they have worked with. For example, 2 years of Spring or Hibernate for a java developer.

I understand that this is based on the complexity of the toolkit, framework or library, plus the competence of the individual developer, however, I'm sure there are reasonable ranges based on time with a language (hence the reference to Senior) that a Senior developer should be able to get competency and be productive.

The reason I ask the question is IT Managers should know this when writing requirements for a position and as a developer, I would like to have a better idea as to what criteria is involved for this type of experience = competency formula that has to exist. Even if it's a rule of thumb only.

What prompted this question is that I've found recruiters, who generally don't have a technical background, are trying to place technical people and they just look at technology buzzwords on a resume and how much experience for each the dev has. The hiring manager oftentimes doesn't have a technical background and does the same thing with the resume and uses his architect or other technical expert to screen the candidate to make sure the resume matches the person in the interview.

The problem here is the perception of "competency" in the mind of the hiring IT manager, whether or not the dev can really pick things up and run with it. They rely on some formula in their mind as to how much experience the dev has with a technology will work for what they want.

share|improve this question

closed as not constructive by Jim G., GrandmasterB, Walter, Josh K Feb 21 '12 at 19:26

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
gladwell.com/outliers/outliers_excerpt1.html. It's quite clearly stated. –  S.Lott Feb 20 '12 at 23:27
9  
@S.Lott what does a list of richest people have to do with competency in a framework? –  dreza Feb 20 '12 at 23:34
    
Malcom Gladwell's book is quite clear on the nature of experience. The excerpt is some kind of sample text. The book is quite thorough. Quite clear. And the "10,000 hour rule" seemed pretty self-evident, to me. –  S.Lott Feb 20 '12 at 23:35
1  
If this is for job postings, then require "competent in X" instead of a number of years. You can then screen for competency when reviewing applicants. –  user1249 Feb 21 '12 at 0:31
1  
@S.Lott: The 10,000 hour rule is for complete mastery. It does not apply to competency. Unless you're expecting every "competent" individual to be classified as a master. –  Joel Etherton Feb 21 '12 at 12:02
show 3 more comments

8 Answers

up vote 22 down vote accepted

The way people know about the book Mythical Man Month - which talks about bogus myth of Man-month in project planning - i guess there is a clear need for another parallel book called "Mythical Man Years" to explain why number of years is a useless metrics to evaluate people.

There are many aspects to explain this:

1. Number of years alone don't count:

In a consulting/project-based IT company - there are often significant periods where staff are on the bench, or where staff are assigned on a project but don't do anything meaningful. Sometimes even if people do some constructive work, there are cases where they have 1 year experience multiplied 8 times rather than doing 8 different things over 8 years.

Choose candidate, based on depth - not length of career

2. What you learn is more important.
Following up, we are talking about how much she/he has learned from others so that now she can apply herself to other problems. There are many people who are so obedient and show successful results by following the boss's nod rather than applying individual thinking. This means if the candidate does not get the support of good colleagues and bosses, they become a disaster (and many candidates themselves don't understand this)

Choose candidate, based on their original contribution than project results and complexity

3. Number of years sometimes is inversely proportional to how much you can learn.

This doesn't have to be true, but it is a possibility. Because someone has spent a lot of time on one subject - they may cease to learn; learning a new framework (details of it) might not be as much if someone has worked in similar level of challenge (and gained wisdom) otherwise. Given this, you can be better off with a relatively newer guy compared to a guy who has some experience.

Choose a candidate who has energy to learn rather than someone tired or who thinks she/he knows everything.

4. New area of work requires new thinking

this implies that often in more senior roles, specific details (how to solve problems with a specific tool) are less important but rather insight on how to approach problems in general becomes more important. It takes wisdom rather than years of experience to foresee upcoming problems.

Choose candidate who has developed insight rather than someone who knows all terms of the API!

share|improve this answer
add comment

Unless I need something done this week, I don't care if candidates have any experience with the technology I am hiring them to use. If I already have one in-house expert, I care even less. In two months a good developer with no experience in a platform will be outperforming the average developer with ten years experience in it. The good developer will read a handful of books in the first month that the average developer has never thought to look at. The good developer will search in the standard library, and then the internet for common functions, while the average developer is busy re-implementing date formatting. The good developer will produce understandable DRY code while the average developer cuts and pastes his way through the day.

Certainly, if I can hire an great developer who knows the platform inside and out, I will, but general ability beats experience very quickly.

share|improve this answer
    
definetly agree with the point, but in many locations, those "good" guys are rare :) –  Ozz Feb 21 '12 at 13:01
    
I agree, but I was thinking more along the lines of how an IT Manager views competency and with the number of IT managers I see without a technical background in IT, perception may count more than reality here. –  James Drinkard Feb 21 '12 at 15:00
1  
@James: Do you really want to work for those guys? Maybe on contract, if you can get a good rate. –  kevin cline Feb 21 '12 at 22:09
    
Almost every place I've worked it's been non-IT Managers running IT. The industry assumption (I don't know if it's still out there) IT is a business and any good manager can run a project! I don't agree, but yes, here in St. Louis lots of shops have non-technical IT managers, not all, but a high percentage. Yes if I get my rate I'll work for those guys. I still get to code and that is what I enjoy. –  James Drinkard Feb 21 '12 at 22:14
add comment

If you apply a rule blindly you will pass over candidates you should hire, and perhaps even hire someone who isn't entirely suitable, because although they have the relevant experience you're looking for, there are other problems.

Remember, that familiarity with the specific framework is not the greatest predictor of success in the actual job. The best candidates will be smart people who get things done effectively and can apply the skills they already have in new ways to problems that haven't been solved yet.

Try not to rule people out entirely at the advertising stage. Instead, find efficient ways to filter the stream of applicants to a level that it's feasible to do short phone interviews with.

share|improve this answer
add comment

Ideally you would never place a specific requirement on experience in a particular framework or library. A good developer should be able to pick up any new framework or library fairly rapidly, so my general suggestion is always try to recruit the best developer overall and don't pay too much attention to specific tick-boxes.

For example, lets say you found an absolutely excellent Java developer who'd been writing GUI apps for 6 years that connected to various back-end servlets that she also wrote. She is motivated, keen to learn, can clearly code pretty much anything in core Java as well as architect complex client/server systems. Would you turn her down just because she doesn't have Spring on her CV? It would in my view make much more sense to hire her and let her pick up Spring along the way. She can lean Spring from other colleagues which she teaches the others something about GUI development....

What's more, good developers are in my experience naturally curious and will generally appreciate the opportunity you give them to learn something new. It's depressing to be hired to do the same thing over and over again.

There are of course some situations where specific experience in a library or framework might be considered very important:

  • In an emergency - if you are recruiting to solve an urgent problem with a tight deadline, then you haven't got time to bring somebody up the learning curve. You need someone who can start cranking solid work out right away. Clearly you want someone with solid experience in the specific library or framework, perhaps 6months+ recent experience.
  • For a leadership / mentoring role - if you're hiring someone to lead, teach or mentor others, then they better know their stuff or they won't be respected and fail badly. Perhaps 2+ years direct experience in the area you want them to teach is necessary, in addition to general experience, talent and seniority.
  • If the technology is fundamental to a field - for example, if someone claimed to be an "Enterprise Java Developer" with "Extensive SQL Experience" then I'd expect them to know something about JDBC. If they didn't then I'd be suspicious about their entire CV... did they really do significant work in this field? Note that you can only check this at interview, since people often leave basic technologies off their CV on the grounds that they are assumed to be there.
share|improve this answer
    
Lets hope her CV gets past the gatekeepers who word match her CV - HR and recruitment agents! –  Ozz Feb 21 '12 at 13:02
    
@Ozz - too right. If you are smart you will either brief your CV screeners very well or do it yourself. I remember once taking a few rejected CVs from the pile and going through with the HR person which ones should have been interviewed (and why). –  mikera Feb 22 '12 at 0:59
add comment

Sometimes a useful proxy for competence in a specific framework is "shipped a product with it." However, shipping a product with "similar" frameworks may be just as good. Also consider how they tested their code in that framework.

Some frameworks are more involved than others and take deeper experience to grok. jQuery for an experienced JavaScript dev who is fluent with Dojo or ExtJS -- no prob. jQuery for a C programmer with no JavaScript -- riskier, since they haven't learned yet how to "think" like a JavaScript dev. Learning all of Spring for a non-Java dev -- risky too -- tools are different, concepts, terminology, even open source may be new.

I do not believe that you only should hire devs already up to speed in tech X, but sometimes the learning curve is too big to absorb right now.. and your question did ask specifically about already being competent.

share|improve this answer
add comment

10,000 hours seems to be the magical number for mastery in anything. Those who get to this point typically spend at least 10 years getting there, although in programming, those 10 years are not typically all spent on a paid job - many programmers start their 'career' at a young age (between ages 12 and 16 seems to be quite common), so it is certainly possible to find a 25-year-old candidate who is already a master in his/her particular field, despite having "only" maybe six years of on-the-job experience.

That said, a lot depends on how much knowledge exactly is required in which area.

Knowing a particular framework inside-out isn't necessarily required for a senior developer role: technologies come and go, and a good programmer can pick up any halfway decent framework in a matter of weeks (days even, if the framework makes sense and is well documented). Skills that are much more important typically include communication, writing clean and robust code, analytic skills, prioritizing, etc.

Of course, if the particular role is that of a 'guru', then in-depth knowledge of that particular technology is the top requirement, but most of the time, you don't need gurus; in fact, they can be a risk. If their specialism goes out of fashion, or gets discontinued, you can only hope that they have acquired a similar level of expertise in a replacement technology by the time you start transitioning.

share|improve this answer
2  
That's the level of deep experience needed to master programming overall, not the level needed to deal with a single library or framework. –  Donal Fellows Feb 21 '12 at 10:52
add comment

If you're asking about competency then I would say just a couple of months of dedicated effort. mastery, as many point out, is generally accepted to take 10,000 hours to achieve.

The times I've had to learn new technologies -- from complete languages like groovy or python, or frameworks like rails, or GUI toolkits like tk and wxPython -- usually take me just a few weeks to become competent. That means I am able to do my job, but that I still have to look things up. It means if my boss says "can you make product x using framework y in language z" I can confidently say "yes".

To me, that's the difference between senior and junior: senior developers can pick up new toolkits, frameworks and complete languages pretty quickly.

share|improve this answer
    
Depending upon the framework, someone might be competent with it in a couple of weeks if there are a small set of parts used often and the rest rarely. –  rjzii Feb 21 '12 at 12:26
1  
@Rob Z: isn't that the case with most frameworks? That you use maybe 50% of the features 90% of the time? That seems to be the case in my experience. –  Bryan Oakley Feb 21 '12 at 12:47
    
I'd be surprised if it is even 50% to be honest, but that is kind of my point, being competent is different than being an expert and the time to be an expert is hard to guess the average for. –  rjzii Feb 21 '12 at 12:50
add comment

It depends, on too many factors for the question to even be relevant as some fresh college graduates could feasibly be competent with a given framework or library just on the basis of where they went to school and how the program was structured. Likewise, once you start working in industry you tend to find that there is a degree of specialization and companies are a various stages with regards to the current cutting edge (i.e. they are still working with Visual Basic 6).

If you are looking for someone to get something done in the short term where the knowledge is a mandatory item then you are better off hiring a contractor to get the work done. If you are looking for someone for the longer term you are better off looking for someone on the basis of what makes for a good developer and with enough industry experience and competency to justify paying them as a senior developer.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.