Slashdot Mirror
Should Younger Developers Be Paid More?
jammag writes "A project manager describes facing an upset senior developer who learned that a new hire — a fresh college grad — would be making 30 percent more than him. The reason: the new grad knew a hot emerging technology that a client wanted. Yes, the senior coder was majorly pissed off. But with the constant upheaval in new technology, this situation is almost unavoidable — or is it? And at any rate, is it fair?"
While I agree that experience should, of course, count towards salary--I've also encountered a *LOT* of IT staff in general and programmers in particular who stubbornly refused to learn anything new after they left college (or shortly afterward). They fell further and further behind and became more useless every day. I have absolutely no sympathy for someone who works in a field as fast-changing as a computer-related field and refuses to learn new skills (including, *GASP*, on your OWN time). These are not professions in which it is cute (or acceptable in any way) to be the old curmudgeon.
Would you want a doctor who still exclusively used surgical techniques from the 50's to perform your open-heart surgery? Would you want a mechanic who hasn't learned anything new in 20 years to work on your Prius? Well, the IT world changes *way* faster than either of those fields.
SJW: Someone who has run out of real oppression, and has to fake it.
The older developer needs to find a new job. IT raises only really come by switching jobs. For some reason companies rather have high turnover and pay each new hire more than give raises to staff. It makes no sense and is not fair, but it is life.
If the senior programmer knows the language or shows an aptitude for picking it up quick(which many quality programmers can do), then I think it's a slap in the face, particularly if the rookie has no realworld experience and no portfolio.
Otherwise, if the senior programmer knows BASIC with no ability to learn C# and the rookie knows C# and is hired for C#, I don't see the problem.
There are a lot of interesting issues here. First, the developer could've trained themselves in the new technology outside the company. Would the company have believed they had the skill? I know I routinely teach myself new things when they look interesting to me. I also know that it can be hard to get anybody to believe I actually know it.
And I don't really feel the developer has complete responsibility for doing this either. A good company will encourage its employees to learn new things and provide training. If they don't, they are basically calling their people disposable. They would rather hire new young college grads, even at a premium salary, than train their existing employees, even if it cost less in the long run.
Lastly, I really think this betrays a bias for youth over everything. And, to some extent, it's a bias I can understand. When I was younger, I wrote more code and faster than I do now. It wasn't as good, and I'm a much better programmer than I was. But companies frequently prefer code that's 'finished' to code that works well. I think it stinks, and I think companies are selling themselves short and limiting their own lifetimes by doing things that way.
Need a Python, C++, Unix, Linux develop
Everything is a commodity.
If you are easy to replace, then you are worth less. If you are in demand and harder to replace - you are worth more.
If senior developer doesn't know this technolgy, they are worth less.
Its not fair. But its expected.
This, and many similar workplace situations:
1. Have zero debt.
2. Have, in a money market account, distinct from your investments, one year of your carefully budgeted living expenses.
When these two conditions are true, conversations with your boss will tend to take a very different tone from most people's expectations.
-fb Everything not expressly forbidden is now mandatory.
Don't concentrate on what other people have. Life isn't fair. Nobody said it would be. Thinking that it should be fair won't give you anything but an ulcer. Instead, concentrate on what you have. Your position, your skills, your pay.
If you aren't happy - leave. Get new skills, get a new job, get different pay.
Basing your happiness on what other people are doing is useless. Concern yourself with your own position. If you have enough, great. If you don't, work on it.
Weaselmancer
rediculous.
I don't agree. The good programmers I know are better in a new language after a week than a "fresh grad" who's studied the language for a full year. The bulk of what makes for quality software is not domain-specific. People who have learned five or ten programming languages already are usually fine in a new one on very short notice.
Age doesn't matter. Experience does, in terms of the actual quality of output you get.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Recent graduates should be making just above minimum wage until they've proven themselves to be anything other than completely incompetent.
Their pay should then rise in accordance with their skills and experience.
Recent graduates are, in general, absolutely terrible. It's insane to pay some idiot kid a senior developers salary because they managed to pull a passing grade on a few practice exercises in C# in college.
Required reading for internet skeptics
even if they are good on paper they might be crap in practice. If you need young hot talent then pay for it, but prepare yourself for disappointment. Cheaper coders might be just as good. Paying for good track record is probably worth the money. Worst thing that companies do is to promote good coders to be managers instead of paying them premium salaries. My analogy that I throw around is that when your guitar player finally learns how to play you don't "promote" him to be a manager and pick new "talent" to fill vacancy.
You are competing for money. Either do what will pay best or leave for greener pastures.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
How did the senior developer learn of the pay disparity?
I have discovered that people can be perfectly happy when they get paid what they think they deserve, and as far as what others make, NOYDB (None Of Your Damn Business). I grew up in an environment where people got fired for discussing pay (just to avoid situations like this).
Clearly, the lesson all developers should be taking from this project manager's example is that:
1. Your work for the current company isn't as valued as the new whiz-bang initiative that the VP is funding.
2. You should allocate your time accordingly. Instead of spending all of your time becoming proficient in the business requirements, and spending your extra hours trying to keep on top of your workload (which only results in their attaching that new kid with the whiz-bang resume like a limpet for you to mentor and transfer your business requirements knowledge), you should instead be spending your time learning new whiz-bang technologies and preparing your resume for jumping ship, since that is what the market is valuing.
3. Thus, by the time they try to screw you over, not only will you have a job at a competitor making a new whiz-bang salary, you'll be helping the rest of us by driving up the average market salary for experienced programmers!
If you are learning ruby to implement the exact same things you implemented before in another language on the same platform...when the world decides that it doesn't want ruby anymore, the time you spent learning it is much less valuable.
Bottles.
Yes, but experience in area Y != experience in area X. No one, no matter how good, is going to master a programming language in a week or even a month. As long as the new hire actually worked and studied in college, he'll be much better in area X than the old guy just trying to learn it. Yes, I'm well aware that once you know one programming language it's easy to pick up another. That doesn't change the fact though that it still takes time to learn it - it just takes less than if you had no programming experience at all.
Mmmm not really. A language is like penmanship. You talking block caps, or cursive, or some weird shorthand script? A programmer on the other hand is a guy whom takes a pretty vague flowchart and fills in the details. Most of the mental effort is figuring out the translation, the error conditions, and especially the business logic or the equivalent. Very little time is spent on the syntax details of how to add the interest to the bank balance, its all spent on the logical puzzles of deciding how to avoid race conditions, how to ensure you do it precisely once per account every time, etc.
Even worse the kid is used to 100 line microprojects or even worse is just good at answering short test questions. No one in the biz ever gets to "start on a blank slate" its all extend extend extend. That and bug fix. And argue with the users about doing dumb things. And work on scalability, theres plenty of really slow ways to do things.
If you get a job in the field, you'll understand.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
That generally depends on what end of stick you're on. Trust me, there's many people that are incredibly petty when it comes to anybody being paid more than them. Particularly if you're being paid for your skills and there's not much formal reasons you can point to. When I was relatively fresh I'd have no problem telling what I got paid to fish out how much they got paid, but the higher my pay got the less willing I am to talk about it. I still discuss it with a few close friends to know where the market is, but far from everyone.
Live today, because you never know what tomorrow brings
Umm, forever(*), at least if you're willing to work at it. Isn't that one of the big features the "open source crowd" crows about? Get it and compile it yourself if necessary.
(*) presuming the CPU architecture itself doesn't change.
Let me see if I've got this right - somewhere in the mists of time, someone at your organisation decided that it would be a good idea to write programs which relied on proprietary extensions not actually found in the F77 standard. Eventually, when you were forced to migrate to different machines, the compilers didn't recognise the attempt to use non-compliant extensions.
Therefore, F77\F90 are both evil and should be done away with in favour of C.
This makes sense... how?
Your quarrel is with the original design of the program, not with the standards. Compliant F77 still compiles perfectly in an F90 compiler. Or, to put it more bluntly, it's no fault of Fortran that you've tried to bring bad code with you.
FGD 135