Slashdot Mirror
Ask Slashdot: Will Older Programmers Always Have a Harder Time Getting a Job?
Theseuss writes "Given the strong youth culture associated with the modern day Silicon Valley startup scene, many times it falls to the 40-year-old programmer to prove that he can still use the newest up-and-coming technology. Yet the rate at which the tech sector is growing suggests that in 20 years there will be a an order of magnitude more 'old-hat' programmers in the industry. As such, do you think the cultural bias towards young programmers will change in the near future?"
Ignore Silicon Valley.
50 years ago it used to be a hot-bed of science and technological innovation. Now it is a magnet for designer coffee-swigging social cloud blog web 2.0 get rich quick smartphone app hipsters.
Look for real companies designing and building real products for proper customers. Silicon Valley's day is gone.
Stick Men
I personally believe that the experience older programmers provide over younger counterparts makes them a desirable hiring option. The catch is that the price has to be right. Some of the older developers demand two to three times the salary of younger programmers. When you do that, you have to ask yourself if you deliver quantity and/or quality two to three times greater than those younger programmers. If you honestly believe you do, then your next task is to prove that to prospective employers, but it's going to be a tough sell. It can take close to a year for someone to realize that they hired a fraud, so you're a more expensive gamble to that employer than a younger employee.
There are certainly older programmers who can produce much better software at faster rates than their younger counterparts, but it is difficult to prove and requires the employer to take a greater risk in hiring you.
Finally, is it me or was there no article at all? Seriously, Slashdot - WTF?
I can say the difference between now and the last time I had to do this (~12 years) is stark.
Seriously...if I have to take another test checking my ability to O(N) a problem, I'm gonna scream. I've been living in ginormous game engines for 6 years, and the amount of times I've had to, in the span of a timed half an hour, optimize a routine to make sure it was running in the optimal time has been....zero.
I'm sure it comes up, and I'm sure it's useful, but this all reminds me of the older assembly guys who used to put in all kinds of wonky tricks that eventually got optimized out by the compiler. Bubblesort has been solved. If your company has to implement it again, you're doing it wrong. There's a routine lying around somewhere in the company. Really.
I don't know what the solution is for evaluating tech talent, but this doesn't seem like it.
Also, web guys...if you're really concerned about speed, maybe you should consider writing some of this code in a lower level language. Plus, if your ad server takes 5-10 seconds to respond, then all of your optimization is for nothing anyway. But hey, you got the O(log N) solution. Bully for you.
Yes, older programmers will always have a harder time getting a job, just like older people in all other professions. Age discrimination isn't just an computer industry problem.
The other advantage 20-year-olds have is they can give their life to the company. They don't care about having to work 60-hour weeks as long as there is foosball and free pizza. Why go home when 'work' is cool?
A 40 year old often has a spouse, kid or two and a dog they might like to take for a walk. They don't care about BS phrases like "Work hard play hard!"
Boy I remember the old days of writing web CGI apps in C, way back in the 1990s. People would look at me like I was insane if I were to suggest writing web apps in a language that compiles to machine code. There seems to be a whole industry dedicated to declaring native apps an evil that must be extinguished.
The world's burning. Moped Jesus spotted on I50. Details at 11.
There are certainly older programmers who can produce much better software at faster rates than their younger counterparts, but it is difficult to prove and requires the employer to take a greater risk in hiring you.
It isn't difficult at all. At my company, an "older programmer" solved a bug in code written by a younger fella by introducing a function that we all never knew about. This fella refactored code, cleaned up the mess we had in our AIX/DB2 system and saved my company lots of cash by single handedly writing code that verified that our data migration to PostgreSQL from the mentioned DB2 system was worthwhile.
Specifically, he wrote code that printed cheques the way we wanted (Numbers to words), in about 1/4 of the lines of code we had. All this by employing functions we never knew existed. Nothing can beat knowledge/experience. Nothing!
I've been living in ginormous game engines for 6 years, and the amount of times I've had to, in the span of a timed half an hour, optimize a routine to make sure it was running in the optimal time has been....zero.
Do you happen to work for EA? That would explain a lot...
today is spelling optional day.
Honestly, any programmer that is worth his or her salt is going to be employed no matter what their age. There are plenty of schools and non-profits looking for help. Of course they may not pay as much as the corporate office, but you'll be working. I also think you should start looking to strike out on your own as a contractor or freelancer soon after 45. I say this as a 52 year old who is exploring other options now. I'm writing some mobile apps for a local school district as part of my community service and I know from speaking with the administrator that I've got at least one way to earn should my company decide to push me out the door with my gold watch.
They usually have experience, but this usually requires that you pay more. If younger workers can do the job well enough, why not go cheap?
Because the cumulative of 20 years experience they are looking for can actually be had by the older worker.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Anybody who gives a shit if somebody's experience is in Java instead of C# (or vice-versa) has no business making hiring decisions.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
As others have observed, older workers tend to want to be compensated for their experience... so they're more expensive.
In a rational hiring world, that might not matter much--they usually deliver greater value, too--but it's often not rational people (or, let's be polite and say, people who could be better-informed) that are making that decision--it's people who want to minimize costs no matter what.
Hire an expensive engineer who really understands the work? Or two young cheap ones who might not? The latter, of course--for the same reason that outsourcing to the third world is so popular despite the incredible hurdles of management and quality. And if the bet fails, and neither of the young'ns can get it done (despite the 80-hour weeks that they can deliver and have come to expect), well, you'll be off to another job by then anyway and no one will know.
It's a vicious cycle: VCs like start-ups that live on ramen noodles because they're cheap to fund, unlike ones that have a real staff and a real track record. And sure, some of those cheap ones will succeed, and they'll get the press (in no small part because they are young), and that will perpetuate the myth that only young folks can innovate, leading the VCs to believe in their own decisions.
I don't see the bias going away. As a general rule, young people are less expensive, more dedicated, more attractive, and just more fun than us old farts. The market want crap in a hurry, and this is one of the primary reasons they get it.
Oh for crying out loud, he wants to be a programmer ... do you know of a single job related injury of a programmer that didn't involve something involving a nomination in a non-fatal Darwin-award category (like chair races)? A freak mouse accident in which someone lost fingers? The coke machine falling on you?
Ever heard the joke about the two bulls on the hill, and one says "hey, let's run down and fsck one of them cows"?
Sometimes experience and having learned some mistakes along the way can be very valuable, because not all of the kiddies have learned these things.
Kids straight of school may churn out large quantities of code and do cool things. But they also haven't yet learned all of the reasons for doing things with caution and diligence and all of the things which come with having spectacular failures.
Eventually, your skillset becomes more valuable for your breadth of experience and knowledge, than your specific ability to code.
For the poster, I would suggest that either you tough it out, or recognize that your ability to provide adult supervision and a longer view might be more valuable to companies (and in the long run you).
At a certain point, if you look like you're just gonna hang on in the corner doing the same old thing until you retire, your company might decide to get rid of you. I know people who started as Help Desk grunts, and have moved on to become Directors of entire departments, because they were smart, learned stuff, and became responsible adults. I don't know many programmers in their 50s who have done nothing but.
I'm in your cohort, give or take a little, there is life after programming. These days, organizations have more of an "up or out" mentality.
Lost at C:>. Found at C.
We have one guy that understands build processes. I have done any serious code in years, but some of the crappy code I've seen is pretty horrid.
Here's an example:
Just over a year ago we had some Java developers doing some web code. This was on a Linux/pSeries hardware. I.e., it's a Power chip, not Intel/AMD. I was asked to install the JVM software by the developers. They gave me an Intel binary. OK, no prob. I asked them to send me the Power installation package. They responded that it was Java and the underlying hardware didn't matter. Oh really? One of the developers actually got pissy and started trying to explain that he ran it on his Windows machine and another guy ran it on his Mac. Tried again to explain the difference between the jvm executable and the jar but then I realized that if he didn't understand that, it wouldn't be much point.
The guy we brought in knows that. Lots of other things too.
You vastly overestimate how much effort it takes to learn a language, at least for somebody who already knows a similar one. As a "young programmer," I started a job at a company using mostly VB.net a few months ago. I had a decent amount of experience with Java, a tiny bit with C#, and more experience with less-related things like C and Matlab. The last time I looked at anything VB-like was VB 6 in elementary school.
You know how long it took me to start being productive in VB.net? 30 seconds, maybe less. OMG, I've got to declare variables as "dim x as whatever" instead of "whatever x;" -- whoop-de-fucking-do! Yes, I've had to look up syntax occasionally (e.g. figuring out how VB.net maps concepts like C#'s ref and out), but as a percentage of my time it's negligible.
Now, if you're asking somebody to switch from Lisp to Smalltalk or something, then yeah, there's going to be a learning curve. But if a Java programmer can't hit the ground running with C# or VB.net then they were never competent at Java either (or vice-versa).
The biggest part of starting any new programming job is not going to be learning the language, API, or any tools; it's going to be learning the company's codebase -- something which job candidate is ever going to have preexisting experience in, unless the company is rehiring somebody who worked there before!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Not true. Those resumes are often lies. I see a great resume that says someone can do the work. And yet they can't wrote up a very simple function on the board, the sort of thing they'd have to do every day on the job. Maybe searching for something in a list is inane, but you'd be surprised how many people with years of C experience on the resume can't actually do it. I feel stupid just asking some of these questions in an interview because they're so basic, but so many people just can't do the basic stuff. Now granted, maybe the recruiters are scraping the sides of the barrel to get these candidates (my theory is that with the current economy that the best engineers are staying put instead of changing jobs).
Ie, Joel on Software mentions some of this, saying that he expects that for the simple questions he would like to see the programers just start writing out the code without pause. And yet I have seen people pause because they can't remember whether to use '~' versus '!' and the like despite a resume that says they should know this completely. I have a really simple question which can be done with a one-line answer that 9 out of 10 candidates can't do.
And besides the programming examples aren't just for checking if someone knows the syntax. We also want to see how the candidate can think about a problem. I try to ask something that they would not know if they just crammed the night before so that it requires them to think. That's important to do on the job: thinking is an important part of the job, whereas bullshitting about what's on the resume is really only useful in the lunchroom. Can the candidate think logically about the problem, or are they flailing about?
Believe me, someone can spend 30 years in the industry and still be clueless. Quite a lot of programming jobs are very basic; in fact right now I think that most programming jobs require minimal thinking, they instead either require mostly gluing together different frameworks, or else making minor tweaks to a large existing body of code.
Where I work, we have several divisions.
One division trains firefighters and EMS. We have an incredible training facility, so not only do we teach Firefighter I, we also train veteran firefighters on extra-hazardous stuff like oil refinery fires. They also teach search and rescue in our rubble piles and collapsing buildings.
Another division trains cops, tactical drivers, etc. That division includes an on-staff sniper.
A third trains people to work on high voltage electric lines.
Then there is my division, "administration". We're the IT people, bookkeepers, etc who keep the agency running. Guess which division had the worst safety record last year. Yep, us nerds. For my employer, the people clicking a mouse had more injuries than the people putting out big fires, crawling under collapsed structures, or performing dynamic entries (seat raids).
Yes, we nerds are suitably embarrased by this fact.
Today, the digital world is young and new
The managers are young, the employees are young, the customers are young
Once upon a time, the railroad was the hot new tech, then radio was, then tv..etc
Someday, software will be as mature, professional and boring as ball-bearing engineering
I suspect that ball-bearing engineers suffer no age discrimination
BTW..I am a 60 year old programmer who is turning away work. I work in the totally non-sexy world of embedded systems and industrial equipment
I am a recruiter who recruits in the engineering spaces and in particular the Oil & Gas space in Australia.
So while not IT it probably crosses over in that we see a significant difference in attitude to years of experience between Australia and the US. For example a Senior Drilling Engineer with 20 years of experience can find it hard to get a job in the US. There seems to be a real preference for people with less experience ie younger.
In Australia the attitude is the opposite. Here the attitude is a 10 years of experience they haven't seen enough to know what not to do and that 20 is what you need to be useful.
Makes my life easier I guess, as we bring a load of skilled people over to Australia but the difference in attitude is interesting.
Yeah, you really weren't productive after 30 seconds. As you said, you can declare a variable, whoopdie-fucking-doo. I fully believe that you could figure out how to write functions that did math functions in 30 seconds. Being productive requires more than that. It only took you 30 seconds to, I dunno, use VB.net to use a COM process to read cells from an excel document?
Which isn't to say you cannot get anything done. But your "general programming knowledge" with a barebones syntax knowledge is not as valuable as you think. If a page of your code can be replaced by a callt o an existant function, you're not being productive.
And I say this as someone who has written professional code in... I lost count somewhere around 15 languages and cannot be bothered to go back and start again. Sometimes I was very productive. In some languages I was not. And in the case of small modifications or small projects, it was okay to be fairly unproductive (I'm using the term how I think you understand it, which means I was fairly inefficent in the use of my time, and the solution, while working, was probably suboptimal). But, the fact that me being unproductive lead to a good solution doesn't mean it wouldn't have taken 1/3 of the time with someone who actually knew the language.
Your ad here. Ask me how!
It's all related to the most profitable configuration for the company.
The problem is, "profitable" usually actually means "what will get me (high-level exec) the most profit in the least time?" Often followed by "before I bail the ship I just helped sink."
Shore that up with bean-counter metrics, projections that fail to properly account for costs (especially intangible ones) and you can easily justify "saving" money by preferring the inexperienced. The only reason why anything has any quality anymore is that advanced manufacturing techniques and materials allows relatively incompetent and de-motivated employees to turn out items that exceed what was possible 50 years ago when low price and cheap junk were more obviously related. Software, however, isn't something that benefits much from microprocessor-controlled fabrication equipment, which is why cheap software is still cheap junk.
The old-time model of a corporation was based on the idea of a more or less permanent core population of differing levels of skill and experience. Since the 1980s the model has changed to the conceit that everyone is an interchangeable cog purchased at commodity prices, used up, and then discarded at will. Except senior management (who are obviously unique, indispensable and irreplaceable, thus mandating extreme compensation).