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?"
The person with 10 years experience has had more failures to learn from. Life experience applies in the programming field as much as any other.
I have slaved away for years to become a programmer who knows the tools of my trade inside out, reading books on this and that, and trying everything within my power to write great code.
Many many programmers aren't like that. They may not be CS trained, not hardcore geeks, or what have you...
Wait till your boss asks you to "dumb it down" and not to use Generics/Templates/Inner Classes/Overloading/whatever, because others are having trouble understanding/maintaining your code.
Wait till they ask you to write it in VB, because Java/C++ programmers are too hard to find.
What scares me the most is... given some of the sad skill sets I have seen in people calling themselves programmers, is that the boss might be right.
In most areas, 2 years is enough time to get someone fairly experienced (they know what to do), but more time is required to have enough experience to become polished and an "expert." For example, after 2 years or practice, you might be an experienced archer, horseman, or cook, but, more likely than not, it takes more time before the knowledge becomes instinctual, you have enough experience to know the various things that can go wrong (how to figure that something has gone wrong based on small clues and how compensate for them), and you can even begin compete with the best.
An analogy. Your boss's son is accused of a crime that he didn't commit. Would he rather have someone who is 2 years out of law school to defend him or someone who has 10+ years of standing in front of juries? Both, in theory, know the law equally well and the general theory of how to defend a client. The 10+ year person who has more experience is more likely to know what will work with juries, how to read them, how to work with judges, how to work with forensic experts, and how to make the best presentation.
Because technology is changing so quickly, having a lot of experience with a particular technology (in this case C++) can be both a good thing and a bad thing.
Good things: Lots of inherent tip & tricks about software design, what works in certain situations and generally a better understanding of what the clients/managers want.
Bad things: Natural inclination to stick to the technology they know best rather than whats the best in that particular situation.
I tend to think people with a lot of development experience should move into becoming technology managers. This is where their experience is most valuable and they will tend to be better at relating to and understanding programmers and the software development lifecycle.
Funtage Factor: Purple
In game development somebody with 2 years of full-time experience has most likely only completed one major 18-month project. From personal experience, it took me three projects (and about five years) before I really figured out how little I knew and I started to become comfortable with diving into unknown code to fix it.
The quality, consistency and performance of the code I write now (after 7 years of C++) blows away anything I wrote as recently as two years ago. And I'm sure I'll continue to improve. Every day I still learn something new. If not a new problem, a new approach to a problem - or a more elegant and efficient solution.
A programmer with 2 years experience and a somewhat grizzled 10-year industry veteran are wildly different beasts. One thinks they know everything, the other knows how little they really know - their problem-solving and abstraction skills are much more concrete.
I'm not in a position to comment on the exact nature of the C++ programmer positions that the article submitter was talking about. But it almost sounds as though they were focusing on a single aspect of development - expecting a programmer to specialize in one thing and never do anything different. If you spend two years doing nothing but, say, building linked lists - your approach is not likely to be very different after 10 years of doing the same.
But not only does this level of overspecialization sound horribly, horribly wrong - it builds unversatile programmers.. but it also sounds like such a position would be mind-numbingly boring. However - I'm sure some people could do it, if they wanted to work without learning anything different. Perhaps your recruiter has only encountered such programmers before.
If he thinks someone with fewer years experience is just as capable of doing his job. (He'll probably say no.) Ask him why.
I think people who have 12 years of experience and are still "programmers" are wasting their experience, and I may be agreeing with your boss here.. but probably from a different point of view.
If you have 12 years of experience, by now you should have collected enough experience to have moved beyond "programming." Your skills are better spent in architecture and software design, and not coding. After a while, the programming language becomes irrelevant, and yes, you can trust the 2+ years programmers to implement what you design. You may be a hot shot programmer, but you can't match the speed with which a proper design is implemented by 12 code monkeys working in parallel.
Yes, I do know that are people who like programming. However most people are expected to grow and develop, and I think architecture/design is on the logical path away from programming.
Just my $0.03.
Your boss is right, and it sucks, and I wish it could be otherwise. Unfortunately, reality is that which doesn't go away when you stop believing in it.
I'm a graduate student. As such, I see a lot of code both from students and from professors. The students have an excuse for lousy code. The professors don't.
In one of the undergraduate CompSci courses, a professor asked on an exam a Java question which could not be answered correctly. If you didn't know Java very well, you'd give an answer which, at first blush, you'd think would work fine, but would have all manner of subtle problems later on down the road. If you knew Java well enough to use a different technique and avoid these subtle problems, you got zero credit for it because you didn't demonstrate any knowledge of how to use the techniques which were being tested on the exam.
I'm not making this stuff up. This stuff is far from unusual; in any reasonably large department there's going to be someone who's too incompetent to ever get anywhere in the research side of things, so where do they wind up? Teaching undergraduate courses instead. The best minds cloister themselves in research and graduate classes; the worst minds get to teach the next generation.
So what happens when these undergrads leave school and go into the real world? Well, if they're talented, smart and willing to work like hell, they'll spend the next five or six years mastering languages and techniques and getting painful lessons from bitter experience. On the other hand, 90% of them say <Keanu> "I know Java-Fu." </Keanu> And they don't, and they can't be persuaded that they don't. Because after all, they have a Bachelor's degree, right? That means they know this stuff, right?
Someone who's got twelve years of C++ experience and has spent those twelve years actively engaged in learning, in developing new skills, in finding interesting corners and how-to-do-weird-things, is a gift from the Almighty. Treasure these people. They are rare.
Someone who's got twelve years of C++ experience and has spent those twelve years doing the same sorts of problems the same way over and over and over again is eleven years past their sell-by date.
There are a lot more of the latter than the former.
Pre-Y2K I was hired by a major telecommunications company. I soon found myself an unofficial liaison to the UNIX development group, because being a recent college grad I understood modern C++. The UNIX development group had a lot of programmers, some who'd started using C++ in 1983... and none of them had kept abreast of the ever-evolving C++ spec past '93. That meant that when we got an updated C++ compiler that was stricter and more standards-conformant, half their code immediately crapped out all over the place, and I got dragged over to the UNIX dev group to walk them through modernizing their code.
So imagine that you're the manager of the UNIX dev group. What you see are a bunch of old graybeards with 20+ years of software experience (and salaries to match!), who are relying on a twentysomething not six months out of college to tell them how to make their code compile.
What would you as the manager think? Would you think "damn, that kid must be really hot!", or would you think "damn, experience in programming is really overrated!"?
Now, these guys who didn't know beans about modern C++ knew every single bug, quirk and weirdness in the phone system. They were walking Bugzillas for phreaking, fraud and mayhem. They knew every RS-6000, they knew every weirdness of our systems. But once outside the very narrow domain of our systems, they were completely out of their depth. They were essentially unemployable as programmers given how dated their programming knowledge was.
There are a lot of guys like that out there. They far outnumber the hardcore geeks who never stop learning and who pride themselves on always staying current.
Ask him if his years of experience matter, or if a manager with 2 years experience can do as well as one with 10 years of experience.
He'll probably say it is different, since his skills involve people. You can point out (if you want to piss him off) that his people skills can't be that great, or he wouldn't be degrading you the way he is. In 12 years someone in ANY field has time to watch the changes, learn the trends, figure out which way things tend to move, and see many, many things that don't work and learn to avoid them for things that do work.
I have been programming seriously for a few years, but will be moving on beyond any programming soon for my passion: writing. (I write poetry and screenplays and came close to writing for Trek:TNG at one point.) I have no problem saying programming is as intuitive as writing poetry and requires the same experience and practice to improve one's art and skill. It seems that your manager doesn't understand this and thinks computers, being made up of bits, can only be but so complex.
Or, there's the other side of the situation: you can't enlighten someone who thinks they know everything. Obviously your boss, who has likely been his job for a while, has NOT learned much about people, but thinks he has. You can't teach people like that. In his case, there is probably no difference in the skills he knew in his job after 2 years and those he learned in the next 10 -- he's too busy saying he knows everything to learn anything.
You said "He believes that people with 10 years experience in C++ have nothing significant to offer over people with 2 years experience."
Everyone comment I've read treats this as a question of fact. I'm guessing it isn't. It's a sociological phenomenon. There are several possible theories. More than one of them could be true simultaneously. Not all of them are mentioned below.
1) He doesn't believe that and is only saying it to you because he wants to act out anger.
2) He believes that. Intimidation is important to him, and he would rather hire someone he is likely to be able to intimidate rather than someone he would be required to respect somewhat.
3) He doesn't believe it, but is saying it because he is trying to hide his jealousy about not knowing very much about technical things. This is common. The logical people, as programmers are required to be, don't get respect from the people who are not able to be logical. To give the logical people respect would mean that he should study how to be logical, and he is trying to hide that from himself, since he has three kids, a wife, a house, a mortgage, other debts, and doesn't have the freedom to improve himself.
4) It doesn't matter what he thinks. He is really, really ignorant. He knows nothing about code quality. In actuality, it is common during programming to discover some serious flaw in the original specifcation for the project. It may take someone with even more experience than 10 years to recognize this and know what to do.
5) His mind is so disorganized that it is impossible to determine what he really thinks, even for him.
6) It doesn't matter what he thinks because you have made a mistake, and it appears to you that he has "considerable hiring power", but that is not true.
7) He realizes that he will be forced to outsource your job soon, and his statement is only symbolic of the true disrespect coming from the company.
Years of experience count for something, but someone with decades of experience of building houses and shoplots won't necessarily be good at building highways, bridges and towers.
;). Better than _just_ watching MTV/Nickelodeon/Disney all day.
It's more using the right tool for the job thing. If he only needs "cheap VB/Java" programmers then 12 years in C++ doesn't count for much.
"Can Slashdot offer up some tangible benefits that can result from 10+ years experience in programming that I can share with him?"
You say you have 12 years of C++ and you have to resort to Slashdot to show why it counts for something?
I'd say it's better to keep your mouth shut till you figure out a few really convincing things. If your boss can't tell the difference between you and a C++ programmer with 2 years experience, it's time for you to get a new boss or prepare for an income impacting incident...
The world has tons of C++ programmers with years of experience, and yet we keep having "attacker can run arbitrary code of his/her choice" problems.
If you ask me, years of experience don't count. Track record counts. Years of "evidence" if you wish.
A programmer who's been churning out crap code for 10 years, is likely to keep doing that.
Lots of geniuses do their best work before they hit their mid/late 20s (I should be sent to the glue factory by now - I suppose that's why I'm using Perl ).
Get some smart 9 year old kids to learn programming in a suitable environment[1] and by the time they're legally hireable they'll be damn good. Once they're past their best they'd probably be married or something then you can "promote" them to Project Manager or something.
[1] They say the best time for people to learn languages is before their teens. Instead of just French/German/Japanese etc, why not C++, Java and LISP as well
You can do 10 years of C++ programming and learn very little. And someone else can do 2 years of C++ programming and be a much better programmer than you (and still "know less" C++ than you).
Some environments also tend to equalize skills. For applications programming in Visual C++, it doesn't make that much of a difference whether you have 2 years or 10 years of experience: the environment ensures a certain degree of uniformity of product. Java and C#, in fact, further equalize the playing field by removing most of the tricky stuff (memory management, error checking, etc.) from day-to-day programming, the stuff that traditionally required skill and expertise to deal with correctly.
By analogy, it probably doesn't make much of a difference to his product whether a MacDonald's short order cook has 2 years or 10 years experience: you get the same predictable mass-market stuff out of him. Yet, there are many restaurants where the difference between 2 years and 10 years experience for a cook are huge.
So, in short, your boss isn't obviously wrong or obviously right--it depends on the kind of work you are doing. If you are doing mainstream application development, I suspect your boss is largely right. (Keep in mind that unlike the MacDonald's short order cook, your standardized mass-market job can be outsourced to India, so maybe it's time to move into something more challenging.)
Sheesh. Let's see, what sorts of things will you know with 10 years experience that you wouldn't with 2:
www.eFax.com are spammers
The answer also depends on the work and workplace. If it is a large IT organization that needs another warm body to crank out code designed by the company's gurus, then the less experienced (less expensive) programmer is fine.
If it's a smaller company and the "programmer" will also be responsible for software architecture, high-level design, purchasing tools, and unsupervised coding, then you want the most experienced person possible. For higher-level software engineering, you want someone with a diversified mental library of patterns, designs, and experiences.
It also depends on the code. If its for small little utilties with a short lifespan, limited userbase, and simple control flow logic, then a less experienced programmer is OK. If the code is mission-critical, high-performance, inner-loop code, then you will want the more experienced person.
Two wrongs don't make a right, but three lefts do.
Not just that, but the quality of experience counts a lot. Most importantly, "official" experience is not any more valid than coding at home as a hobby. I know some ppl who have many more years of experience than me, and their code stinks. Never seen such badly architected crap.
To work on my team, I'd rather have someone who's been coding as a hobby since they were 10 and is fresh out of uni on a completely different degree than someone who's done a degree in CS and has 5 years of experience in the software industry.
Daniel
Carpe Diem
Depends on what you mean by "pick up". I consider myself a very good coder, with over a decade's professional experience and about five years of working with C++. But it's a very "deep" language; I doubt anyone who's not named Stroustrup fully understands it completely. There are features of it I've never even touched. (The first C++ environment I used, back in the early 90s, didn't even have exception handling, much less the STL.)
In contrast, I've been working with PHP for about a year, and I don't think there's much significant to it beyond what I've seen. It's a shallow language.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood