As stated by the title, what is the difference in years of experience in given language in terms of developers? For example, if one developer has had five years working with language A and the other developer has had two years working with language B followed by three years working with language A, would there be perceivable difference between them?
closed as too broad by durron597, user40980, user22815, Kilian Foth, GlenH7♦ Jul 8 '15 at 19:35
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Experience <> knowledge or understanding.
Programmer 1 could be very good, a guru even, or they could be someone fumbling around with the language for the last 5 years.
Programmer 2 could be someone who understands concepts independently of language they're using. Or someone who found language B too difficult and hopes A is easier.
Coding Horror's "The Years of Experience Myth" is worth reading
Yes, Programmer 1 has no syntax knowledge of language B.
Programming concepts are programming concepts. The language is merely syntax.
Of course, the developer who has more years of experience in one language will have a better understanding of the core libraries and idiosyncrasies of that language. If the languages embrace the same paradigm (imperative vs functional) then they should not have any more trouble picking up that language other than learning that.
My greatest difficulty picking up a new language came from trying to switch from C# to Erlang, because it represented not only a new syntax but a new way of thinking about programming as well.
I have a friend who tends to stick to one language, so if you considered him "programmer A" he's got 1 year of experience with that language, five times.
Different languages let you do different things. One essay I particularly like is called "Beating the Averages" by Paul Graham. In it he is trying to convince people to learn lisp, but he also makes some very useful points:
Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.
And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
Generally, my advice is to learn more than one language, and to learn what languages' strengths and weaknesses are.
Here is what I would expect/hope:
- Fluency - they should be able to write more code off the top of their head and less time looking up syntax.
- Know the difference between previous and current versions and how to migrate code from one to another.
- Have a fuller understanding of compiling, distributing, testing, and creating upgrades and patches.
- Create/Include Add-Ons to the IDE and gain efficiency from them.
Languages aren't the issue. You can learn an entire language in a couple of days. What takes longer to absorb are the conventions, APIs and various third-party frameworks. When people ask for five years of X, they don't care about the language, they want someone that has a lot of experience solving problems in and with that language so that they don't have to pay for any of the learning curve.
And you're using them for language A, I assume? (Clearly, there would be a difference in language B.)
It partly depends on the differences between A and B (particularly if we shorten the second developer's experience with A). If they're fairly similar, there will be essentially no difference in experience. If A has considerably different concepts, three years is still likely enough to learn them. Given a very large library and complicated tools, there may be a difference between three and five years.
Of course, what matters most here is the individual. A good developer can learn a new platform thoroughly in three years, and so this shouldn't be an issue.
"Years of experience in X language/platform" is largely a recruitment pathology...
It's open to interpretation and isn't anywhere near as useful as it looks at first glance. As has been said, the Years of Experience Myth is a good read.
Also, crucially, the measurement of "years of experience" itself can be very inaccurate. Here's an example from my current gig: my main task is developing and maintaining a Java web app. However, this runs off a back end which is MFC/C++/SQL Server. Consequently I'm dealing with C++ code on a virtually daily basis too. BUT - this C++ experience is relatively superficial and maintenance-oriented, and I don't really write entire big components or programs from scratch in MFC/C++ anymore (I used to in previous roles though).
Can I still count these last 5 years as "5 years of C++ experience"? Maybe. Maybe not. Depending on how I want to sell it to secure a particular role, I can easily overplay it without outright lying, or I can admit that it wasn't really a 5 solid "years of C++ experience". :) I'm sure plenty of cases out there are similarly open to this kind of "inaccuracy of measurement" problem. Depth of experience can grossly cloud the quality of experience. So an "X amount of time spent with C++" doesn't mean much in itself.
I would agree that language is language and concepts are concepts.
My problem is that there are a large number of programmers these days that without a sophisticated IDE they could not program at all. They are really not programmers but are really more like designers.
I know from personal experience that there are a lot of people that have been seduced by the draggy - droppy Microsoft development environment. It is not Wrong that they drop a textbox onto the screen then set the properties with the wizard and drag the data from a picture of the database, but are they really coders in any language if all they do is set up basic equality tests?
Those folks are never going to be able to take the Concepts they have learned and apply them to another language.
When I Interview folks I am more interested in how they did their development and what frameworks they used. I like to ask questions like, "How do you write an event handler?", "How exactly do you put the data into the DB?", or even "How do I turn this particular button purple when I click it?" this will quickly weed out the designers and leave the programmers. I have found that 3 or 4 years actually programming with a year in my language of choice is sufficient for what I need.
Just another opinion,
Expertise and deliberate practice.
If you don't practice deliberately, you will not gain expertise. (You must examine your errors and correct them, practice what you are weak at, and having an expert to tell you what you are doing wrong helps too.)
If you don't try to improve, you can be a newbie forever!
After ten thousand hours of deliberate practice, you'll achieve expertise. (This finding from education/training is all over the net.)
If your programmer A hasn't been deliberately practicing, they never get better.
If your programmer B hasn't been deliberately practicing, they never get better.
One other finding from the same research: that if I've got 15000 hours and you've got 10000, and I keep practicing and so do you, you will never be better than me.
Knowing two languages will probably make B a better programmer (subject to practice rules).