Is Experience in Programming Worth Anything?

damphlett asks: "My boss is a person of considerable hiring power within the Software Development area of a major global Investment Bank. I've just had a conversation with him that scared the hell out of me. He believes that people with 10 years experience in C++ have nothing significant to offer over people with 2 years experience. As someone with 12 years C++ the difference is so self evident I barely knew where to begin explaining his error, but he won't be convinced otherwise. Can Slashdot offer up some tangible benefits that can result from 10+ years experience in programming that I can share with him?"

Comments

Re:The difference

[AnwerB]

I remember reading somewhere that the difference in efficiency and productivity over the life cycle of a software product is quite dramatic between good software developers and poor developers. The report I read applied specifically to embedded firmware developers, but it probably applies to some degree to software development in general:

The difference between the top 25% of productive development teams and the bottom 25% is a factor of 5. i.e. productive development groups are 5 times more productive. For individuals, it's even more dramatic; productive individuals are up to 10 times more productive than their less talented compatriots.

This counts time spent redesigning, and the amount of effort that must be spent debugging bad code, etc., and not just lines of code.

One of the first authoritative book on the special nature of software development management is called "The Mythical Man-month", and has just been reissued in a new edition. You might want to stop by your local bookstore and see what it has to say.

One advantage of 10 year experience

[wowbagger]

We are hiring and with that much experience you have a pretty good shot. Show your soon-to-be former boss what good experience is.

Sheesh. Let's see, what sorts of things will you know with 10 years experience that you wouldn't with 2:

1. The only constant is change - specs change, languages change, chips change. At two years you haven't seen as much change, and you think things are relatively static.
2. Macro-optimization. Suppose you have a program that does lots of string compares (like a language parser). At 2 years experience you probably would try things like inlining the string compare, or the "if (a[0] == b[0]) return strcmp(a,b); else return -1" trick. At 10 years you do things like making your String objects have a hash code and doing a simple single int compare. In other words, you learn to optimize ALGORITHMS, not implementations.
3. Compilers lie. At two years you think the problem MUST be in your code, because you have not yet learned that compilers have bugs, and sometimes mis-compile things. At ten years you learn that most of the time you screwed up, but SOMETIMES the compiler screwed up - so you get a mixed assembly output and doublecheck
4. Neo-phillia. At two years you jump on every new thing, because you think it simply MUST be good. At ten, you learn to sit back, evaluate, and then implement in an experimental context.
5. Documentation. At two years you hate doing documentation. At ten you hate doing documentation, but you hate NOT HAVING DOCUMENTATION EVEN MORE.
6. Project maintainance. At two years you figure if it can be compiled on your machine, good enough. At 10, you learn to make the build proceedure as easy as possible, so that newbies can come on the project quickly, and so that you can recreate the project easily after several years of inactivity.
7. The difference between being productive and being busy. At two years, you think that working 60 hours a week, always in crisis mode is being productive. At ten, you learn that the most productive people get more done in 40 hours a week, calmly. Crisis are to be avoided by forsight.