Slashdot Mirror
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.
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.
Most programmers take three years to really 'get' C++ and once they do, any additional experience is of value if it broadens out to particular API. So for example, if I'm looking for a PS2 developer with vector unit experience, an applicant with 1 year of C++ on a PS2 that includes some low level experience will be preferred to an applicant with 10 years MFC C++ experience.
Essentially, its the application environment that is the valued experience after 3 years of C++. Less than 3 years, I need to see if they actually know C++. So your boss is only a little wrong.
1000s Warcraft Gold while you sleep
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.
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.
.. is pretty bad for the long time survability of the project as generally there will be less chance of finding good C++ programmers than a crappy C programmer.
IMHO all good programmers should think about what will happen if they leave. That is, if you do use all the exotic features of the language then you have to understand that it will be harder for management to find a replacement for you.
Hence things like templates/overloading whilst great for you and usually for the project
Funtage Factor: Purple
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.
Of course, C++ is here to stay
I can remember when everyone was saying that about Cobol. Everyone I went to college with who was a CS major (I wasn't) was getting jobs in Cobol, even though the Computer dept. didn't teach it. (They had to take Cobol through the business dept.)
That's one part of the "good ol' days" I definitely do NOT long for.
Those are all fine journals and excellent resources from the programming culture. However, most bosses don't view programming as an artisan's craft.
Using all the fancy trendy methodologies of the day is dangerous in day to day business, because it adds a tremendous amount of complexity to what needs to be straight-forward code. Businesses are NOT enthusiastic about hiring a priesthood of artisans to run their backoffice.
resigned
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.
Here's but a tiny fraction: Bitwise arithmetic, polymorphism, virtual functions, template templates, operator-overloading, cast-overloading, low-level memory pointer casting tricks, optimizations, prime fields, and of course the STL ... these things alone take quite a bit of time to learn. If your boss believes that even this chunk of concepts can be digested into a form in such a way that could possibly give equal footing to people with experience levels differing by as much as 1/6th, then he's got some explaining to do.
... then we must focus on style and habit:
... you're doing what works. You're not still practicing "binge" programming where you work 11 hours at a time or more (20+ at a time for those in late teens/early twenties who want to destroy themselves) -- instead, you work smartly, with breaks, and in a more reasonable fashion. You have a planned structure even before you start to code. You're so familiar with the language enough that if there is something new, you assimilate it quite easily into your own ADT<tools> of tricks.
... all in good, respected time.
:-)
Still, maybe a person with a background in C with C# and/or Java could theoretically master C++ in a short period of time.
But, let's just ignore the semantics and tricks, for a second, and simply assume it IS easy to pick up in two years, since not all people learn at the same speed, so there should be at least a small-medium-sized amount of 2year-experienced brilliance
Nutshell: The differences are familiarity, code modularity, and time/energy efficiency.
Verbose: By 12 years, it's like reading and writing. You debug your code before you write it. You know every possible mistake your code could come up with, across various compilers, and how to deal with one when it arises -- since you know that no matter how good you are, errors will crop up. On the other hand, two years of experience can still have you wracking your brain for a hideously irritating and trite error that you've somehow overlooked.
Your ever-growing library of re-useable code snippets can, by now, create at least a working framework for anything under the sun within any requested period of time.
Speaking of time, you can save lots, since you're not trying out ideas which are new to you (and old to everyone else)
That is what experience means, and it is attainable by anyone
PS - C++ ain't goin' nowhere. And if you java/C++ programmers want somethin' really interesting to chew on, go to s-mail.org and look at this guy's minimalAPI src2src conversion code.
--I gots 99 problems but a new machine ain't one!
AMD! Asus! Whoot! 6 years!
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.)
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.
You are asking about one of the fundamental flaws in your chosen profession, and one of the key reasons I stopped trying to work as a programmer years ago. Fact of life: Managers don't look at what you can do, they look at what you have done.
.
.
The same technician-manager conflict arises in virtually every technical profession; ask any experienced engineer, or even a good welder. Management and HR can't judge ability from your resume; they can only judge success. But I've said for years there's no technical job in which sheer incompetence can be so easily disguised as in programming. The imbalance is more severe, because the true incompetents are so much more dense (in more than one sense).
And management knows it. Hiring a programming team is a crapshoot, because you may not find out for years which of them is worth the money. Experience is superior to education, but it's far easier to see if a welder can lay a bead cleanly than if a programmer can write 10K lines of clean code.
In my day I wrote payroll software in Fortran, library routines and system utilities in assembler or PL-6, and database applications in (gack!) COBOL. Fortran was clean, assembler and PL-6 had system-level access, and HAIRBOL had database functions built in. I used what I had to, however it worked. I didn't think of myself as a Fortran or COBOL programmer; I thought of myself as a system programmer and (in occasional moments of overconfidence) a system designer.
But to prospective employers, I learned, I was not a system designer or a system programmer; I wasn't even particularly a Fortran or COBOL programmer. I was a Honeywell programmer because that's the hardware my company had. I was a accounting programmer because I'd written accounting software.
So the way you phrased your question catches my ear. First:
As someone with 12 years C++ . .
but then:
. . . from 10+ years experience in programming . .
Which is it? Is your boss looking at the amount of time you've spent in C++ (and you should learn even a complex language thoroughly in 2 years) or at your body of work as a programmer?
The manager who needs a search engine would rather hire a kid who spent 2 years coding someone else's engine than someone with decades of design experience from accounting to gene sequencing who has never done a search engine. But the manager who needs a design team leader will look for someone who hasn't turned all his projects into lumber because the only tool he knew was a handsaw.
In conclusion (I ramble too much to say in summary), I believe this is an argument you can't win--you can only outlive it. Tangible benefits from years of programming experience take years to reveal.
I figure by 2030 or so my 6-digit UID will be something to brag about.
But with lots of experience, one knows what WORKS and what doesn't! Something that seems innovative will not usually work, but something that has worked a million times before usually will. Sometimes just working is better.(Emphasis mine)
Does that same train of though applies to people like The Wright Bros., Copernicus, Socrates, etc who went against conventional wisdom?
Flying is not something humans will ever be able to do... Conventional wisdom before 1900 (except Da Vinci)
Earth is the center of the galaxy... Conventional wisdom before Copernicus.
Justice is a bad and injustice is good... Conventional wisdom before Socrates.
Unconventional approches to a problem (regardless of the area) can sometimes lead to huge breakthroughs.
This is the Internet. You can say "fuck" here. - AC
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