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

[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

[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

[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.

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: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.

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)