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?"

Comments

Keep up or shut up

[elrous0]

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.

Re:Keep up or shut up

[somersault]

the IT world changes *way* faster than either of those fields.

Things change fast sure, but by that token, not all of the changes are permanent or important. I'm not averse to learning new stuff if it's proven, but I don't go running after new stuff simply because it's there. Old programming languages still work fine for new tech if they have appropriate libraries, etc.

Re:Keep up or shut up

[elrous0]

Well, ask yourself this. If your boss came to you and said "We're working on a new project and I want you to learn how to program for the iPhone" would you argue with him for an hour on how the iPhone sucks, or would you embrace it as a new opportunity to learn something new?

That's the difference between someone who's intellectually curious (and always looking to better themselves) and someone who's dug their heals in and is becoming more a liability every day.

Re:Keep up or shut up

[Svartalf]

The big problem is...you're presuming that the Senior isn't intellectually curious and they're basing the pay discrepancy on just that alone. Neither of which are likely to be correct a assumptions.

Re:Keep up or shut up

[icebike]

not all of the changes are permanent or important

So true.

The industry is full of fads, new names for old concepts, and hucksters selling the same snake oil. All too often the new kid comes in all gosh and golly about something the old fart has known under a different name since the Pleistocene.

Still you have to lean about these things to even make that assessment. The older programmers have to at least be conversant with the newer languages, IDEs, file systems, databases, or platforms to be able to exercise all of that accumulated experience. You can't judge what you refuse to learn about. You can't delegate the acquisition of knowledge.

It is virtually NEVER worth while changing programming languages via a re-write. More bugs will be introduced in the re-write than utility gained. But the same can not be said about platforms or database technology.

If the senior staff have an education allowance in the company budget, and fail to use it, shame on them.

If on the other hand the company is just getting the latest techniques and theories by hiring kids with no real world experience, then they will probably pay dearly for the privilege.

Someone else paid for that whipersnapper's education. It looks cheaper to HR. But the company already paid for the old goat's experience, scars and all. He walks, and the kid is at sea.

Experience is all too often undervalued. Inertia has its place. Its the older staff that can distinguish opportunity from pitfalls. But opportunity does knock. Softly.

Re:Keep up or shut up

[Kizeh]

All of this conversation is a lot more idealistic than what I've seen in the places I've worked -- which is that when a new position opens, the employer looks to see how much they have to offer to get qualified applicants, and does this. The existing workforce doesn't get raises, or only gets a pittance, and so the newest hires almost always make the same or more than veterans. Existing workers face the option of either finding jobs elsewhere to stay within the pay curve, or staying in a comfortable environment where they know the culture and can be productive, until they get sufficiently pissed off at being rewarded for loyalty with being paid less.

Re:Keep up or shut up

[narcc]

This is a neat discussion. You can guess someones opinion with surprising accuracy based only on their user id.

A senior developer should not only be able to pickup a new language very quickly, but also write more competent code than a recent college grad who has used the language in class for the last 3 years.

If your senior developers don't meet this criteria, you probably should have sent them packing years ago.

Re:Keep up or shut up

[BattleBlow]

Did you even RTFA? Here is a quote: "I felt like I was letting down one of our most promising engineers. He was someone who had the most knowledge about the business we supported and was an expert in the core client-server application. " It wasn't someone sitting in a corner shooing kids off his lawn while he became an old curmudgeon, it was the team lead in the core application. I don't know about you, but I don't always have time to become an expert in every new IT technology that comes along. I have limited time and so I pick and choose. This guy had spent his time working hard and becoming their team lead, which naturally meant focusing on their core business and application. He then finds out they're hiring graduates at a 30% higher salary and expecting him to mentor them in the business requirements because he hasn't also had time to become an expert in mobile applications. Tell me you wouldn't be pissed off in such a situation? Yes, the salary for the graduates was driven by the market, and purely from a fiscal perspective the company did the best thing for it. Let's not pretend though that there aren't people involved and that they weren't screwed.

Re:Keep up or shut up

[timeOday]

Senior devs find it difficult to keep up with new technologies because the company is too busy milking the existing skillset. They're not going to excuse you from your current job just because it's a dead-end leading to career stagnation; after all, they really need somebody to do it, for the moment.

Re:Keep up or shut up

[mellon]

Be that as it may, it's nearly always the case that you can increase your salary faster by keeping your skill set current and job-hopping than by staying in the same job, whether you keep your skill-set current or not. When you get a response like this from your management, the right thing to do is to figure out how to make yourself more valuable, and *change jobs*. Your management already knows what you're worth, and the only way they'll ever learn otherwise is for you to decide to leave. When you do that, they will either correct the discrepancy or let you leave.

Re:Keep up or shut up

[Belial6]

One of the stupid things that this points to is that the companies have no problem spending the money and man-hours to train the new hire the business side of the job, but not the money and man-hours to train the existing employee on the new technology. In all but the simplest of environments, the business side is WAY more complex than the technology side, and you have a proven track record with the existing employee, while you are taking a big risk with the new hire.

Re:Keep up or shut up

[cptdondo]

That seems to be an old tried and true way. You count on the people you have staying even if they're paid less; they have some "inertia" they need to overcome to move. You hire the young guns with big $$ and as soon as they sit down their pay freezes.

I used to work for an outfit where that was more-or-less policy; you quit, if really they needed you they hired you at consultant wages and then negotiated new compensation.

It got to be a game; you'd game the system to where only you had the critical information for that critical project and then, with deadlines looming, you'd quit. The PHBs hired you back in a panic with a nice big raise.

Of course, that meant that no one shared any information and the atmosphere was completely toxic, but that's how you got raises.

Re:Keep up or shut up

[Blakey Rat]

There's also a lot of people in IT who are too timid to ask for raises, and aren't being paid what they're worth. That's a factor.

Re:Keep up or shut up

[turbidostato]

"Nobody needs to know what you make, and honestly it causes nothing but trouble."

Specially for the company.

Information is power. The company knows what each and everyone makes, you do not. More bargaining power for the company, less bargaining power to you, little bee.

Re:Keep up or shut up

[tnk1]

This is why it is almost essential to not only keep up your skills these days, but also consider switching jobs every so often, at your own pace. It is possible to get a decent raise every so often, but honestly, most of the time it is the old 3% raise to keep up with inflation. Real raises come from offers from companies that you have spent a good long time looking around for while you work at your current job. If you are not at least passively looking for a new job at all times, you're doing yourself and your career a major disservice.

And yes, loyalty in corporate America is dead and buried. No one says this, but everyone these days gets really excited when new talent shows up from the outside. Once you have been there awhile and collected a few merit raises, you become part of the woodwork. The senior guy in this article became part of the woodwork, no matter how skilled he is, no matter how much he really did do to keep himself up to date, if you are part of the woodwork, you get taken for granted. They know they can keep paying you 3% raises every year because you've taken those raises every year and not quit.

When you go looking for new jobs, you find people who may well need your skill set and are willing to pay for it. One company's curmudgeon is another company's rock star. If I was this guy, I'd have not complained in the slightest. I'd have figured out what this kid knew, taught enough of it to myself to be able to truthfully note it on my resume, and then went somewhere that needed that skill and got myself a cool 30% raise, because I now actually know that I can make that sort of money for that skill.

Pay is based on experience but also on skills and the demand for those skills. Java programmers are a dime a dozen, but if some company really, really needs someone who is a FORTRAN god, those people will make good money no matter what age they are, because chances are that demand outstrips supply (of coders).

It reminds me of when I was in college and I was hired as a research assistant simply because I was *willing* to learn FORTRAN. I had never seen the language in my life and I wasn't exactly a CS student to begin with. I said "I'll make it happen" and I went to the library, took out an ancient FORTRAN book and taught myself enough of it that I could pull stock information off of a tape system hooked up to a VAX. This was in 1995, so was not quite as crusty and ancient as it would be today, but it was still damn old. Compared to my other work-study jobs, it was both easy and well-paid. And that was with zero experience, just plain demand and willingness to try.

Which reminds me. I am still surprised that I actually liked FORTRAN as much as I did. I thought it would suck ass, but it was actually pretty cool, for what it was.

Anyone out there willing to pay $200K for a FORTRAN coder? Experienced. :)

As college student studying computer science

[igreaterthanu]

I say yes!

Life is not fair

[h4rr4r]

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.

Re:Life is not fair

[quanticle]

IT isn't the only industry where this is the case. This (lack of raises) is a byproduct of the change from the old world, where companies guaranteed raises and promotions and workers promised loyalty in return. Corporations have broken that bargain - promotions, raises, even employment are no longer as secure as they used to be. As workers, then, we'd be fools to give corporations the same amount of loyalty workers used to give in the sixties and seventies.

Its a new world now, with new rules. As a worker, you're more free to move about and find the best offer. As a corporation, you're more free to hire and lay off workers as necessary. But it is a drastic change from how it used to be, and both workers and corporations need to make adjustments.

maybe?

[bhcompy]

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.

This isn't an obviously easy question

[Omnifarious]

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.

Here is how you handle this

[fishbowl]

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.

Re:Here is how you handle this

[EnglishTim]

This, and many similar workplace situations:

1. Have the power of the force.
2. Use Jedi Mind Control during negotiations.

When these two conditions are true, conversations with your boss will tend to take a very different tone from most people's expectations.

Life isn't fair

[Weaselmancer]

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.

Re:The Real question is...

[seebs]

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.

Coders are like professional athletes

[LucidBeast]

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.

FORTRAN

[mangu]

Old programming languages still work fine for new tech if they have appropriate libraries, etc

I have a perfect example on how wrong you are: Fortran.

I do a lot of engineering software and a lot of that is in Fortran. A few years ago I migrated a system with 400 thousand lines of VAX-Fortran code to Linux, using g77. Recently I had to install this system in a new computer, running Ubuntu Lucid. To my dismay, I learned that Lucid doesn't have the g77 package anymore, the gcc compiler suite has been "upgraded" to gfortran. And gfortran does not support the VAX extensions that g77 did.

Luckily there's still a way to install g77 in Lucid using the Hardy repositories, but how long will this last?

Had the old engineers said, "OK, Fortran is dead, let's just keep a legacy compiler to run old code" everything would have been fine. But no, they insist on "improving" Fortran by putting C language features, e.g. pointers, into it. Why can't they just learn to program in C and let the old compilers do what they are good for, which is running legacy code?

I once signed a petition to retire Fortran, where the best reason why experience isn't always welcome is stated: "In order to best serve future generations of scientists who rely on numerical simulation, we propose that FORTRAN be retired, allowing its successor(s) to evolve in the absence of the legacy FORTRAN juggernaut. Until FORTRAN is formally retired by the J3 Committee, institutional inertia will prevent alternatives from being adopted by science and industry"

The current Fortran standard is the worst of all possibilities: unable to run legacy code which is stable and tested, and unable to compete with modern languages in either execution speed or programming ease.

(And before anyone comes with some contrived benchmarks "proving" that Fortran code executes faster than C, let me point out that the legacy Lapack code is optimized in Atlas by compiling key functions in C+Assembly code)

Re:FORTRAN

[Anonymous Cowpat]

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.

Re:so how did he know the pay?

[v1]

I'd generally agree with that... the managers usually say "you're not supposed to discuss each others pay". Meaning "We don't want you to know you're being underpaid".

Coworker here recently got... check it... $0.25 raise. Oh he was pissed. And there was much yelling. I remember that being brought up later with regard to reviews and raises, in a critical way, and being told "he wasn't supposed to discuss that with anyone", as though it wasn't a valid point to raise during the discussion. I suppose not, that's both insulting and embarrassing at the same time.

Re:The Real question is...

[vlm]

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.

Re:so how did he know the pay?

[Kjella]

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.