Slashdot Mirror
Programmers: It's OK To Grow Up
Nemo the Magnificent writes: " Everybody knows software development is a young man's game, right? Here's a guy who hires and manages programmers, and he says it's not about age at all — it's about skills, period. 'It's each individual's responsibility to stay fresh in the field and maintain a modern-day skillset that gives any 28-year-old a run for his or her money. ... Although the ability to learn those skills is usually unlimited, the available time to learn often is not. "Little" things like family dinners, Little League, and home improvement projects often get in the way. As a result, we do find that we face a shortage of older, more seasoned developers. And it's not because we don't want older candidates. It's often because the older candidates haven't successfully modernized their developer skills.' A company that actively works to offer all employees the chance to learn and to engage with modern technologies is a company that good people are going to work for, and to stay at."
they just happened to have learned the most recent stuff (which all too frequently is all the managers care about)
The experienced developer will know when not to use a new fad because they will have seen a prior version of that fad before.
We want people to spend their own time and money to train the skills that we need. There's no way we would invest in such things -- it hurts the bottom line!
One of my colleagues in in his mid-60s, and happily puttering around in modern technologies and adapting what he knows about systems to the latest tools. Writing prototype code in Clojure, using network databases (neo4j), doing interesting data modeling and generally just making stuff happen. He's learning new stuff every day, having fun - and getting to say no to job offers on a regular basis. I've been in this industry for more than 30 years and I'm currently mucking around with Hadoop, cloud computing and a bunch of the new things.
People talk about time to learn, but it's a question about making time. Would you want to visit a doctor that hasn't updated their skills in 20 years?
Alan.
Buzz word, buzzword, markup language.
I find it difficult to believe that a developer would NOT be able to pick up HTML5 in a weekend.
When you go to hire a developer you're not just looking to hire someone who can code in the latest fad language/API/SDK. You need someone who knows software development like a captain knows his ship. I promise you that 20+ years of software development will be worth way more than the 22 year old kid who knows Ruby on Rails because he learned it while studying in college. That experienced developer can pick up whatever tool your company standardized on and yeah, it may be three months before he's all the way up to speed on it, but then the years of experience will begin to make themselves tellingly felt vs. a kid who happens to know the tool already.
Hiring for the tool is stupid. It would be like looking for a columnist who specifically has Microsoft Office 2013 experience and filtering all the applicants who only used Google Docs in their previous jobs. Either one of them can write copy.
it's about the money. same with age.
Even better would be the 20 year veteran who can take those fresh out of school enthusiastic newbies and get high quality software out of them on a predictable schedule, without the "back in the day, we coded with patch cords on EAM equipment". Or the 20 year vet who is doing the new stuff and the old stuff, and can help the inexperienced new stuff guys and gals avoid the traps.
Face it, on a large project, there aren't enough skilled veterans on the market to get the job done, you MUST do it with average or below average folks. The challenge is seeding the crowd with just enough experience so that all those contributors are net positive, no matter how small.
I am so sick of this same FA reposted more or less every week or two.
Companies often times prefer younger developers because they are cheaper. It is as simple as that.
That older, incompetent developer was probably just as incompetent when he/she was in their 20's.
We've hashed this out on Slashdot before, more than once. OP is just wrong that older programmers in general don't keep up.
Study after study have shown that older programmers are generally more productive, even after adjusting for the higher salary they tend to expect.
While he appears to be genuinely sympathetic, his personal theories don't quite qualify as statistics.
make me!
Table-ized A.I.
I've found that young vs. old is a trade-off.
Older workers frequently have a better work-ethic in the workplace, and have more experience to draw upon. Younger workers have a better work-ethic in terms of the amount of time they are willing to dedicate to work and frequently (but not always) contribute new ideas.
What it seems to come down to is: do you want experienced workers who will contribute more per hour, but who will also draw a firm line between their work and personal life, or a young worker who is willing to put in the extra time, even though a lot of their time will be spent relearning what a more experience worker already knows?
I suppose software development also has other factors. Some products depends upon experienced developers (e.g. anything considered mission critical) while other products depend upon fresh ideas (e.g. most software targetted at consumers).
Doctors have been doing it for decades if not longer.
Doctors get paid a hell of a lot more and can get meaningful amounts of paid time off to do such things in.
Back in the 1980s, I had the good fortune to work with a man who had started at IBM the same year I was born. He not only knew the current landscape of development tools, he also had a vast knowledge of how we got here, what things had been tried and abandoned along the way, and he was very good at spotting tasks that people hadn't realized were necessary. I learned a lot from him.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
As programmers get older they simply get less excited about the idea of pulling all nighters and doing "code sprints" because they have spouses and families they enjoy, responsibilities to others outside of work, and they know that this isn't a good process for long-term success. All nighters are fun and adventurous when you're in college or just out of school, but after a few decades in the working world you're seen it all before and simply refuse to get caught up in another "emergency" caused by poor planning, unrealistic expectations, and marketing promises.
I'm not saying that programming is a young person's game--far from it. However, inexperienced workers are not only cheaper, but also far more likely to put up with bullshit and bad management.
Who is a friend of mine that said to me casually, "Yea I wanted to build a team of young people that I could hang out with so I didn't hire anyone old". Old here being over 35!
In IT, age discrimination is blatant. It starts at 45. You should always keep your skillset up- but it probably won't help much because many young 28 year old managers are just flat out not going to hire an "old geezer" who is 45 unless they are the only viable candidate.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Problem is convincing a PHB that the seasoned veteran who knows the codebase extremely well is worth the cost compared to a H-1B
The the companies problem though, not the seasoned veteran - because the seasoned veteran is already considering several job offers from people who do realize that value.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Actually for me, keeping up would be learning Java. Most things newer than that are irrelevant for most things I do. I used to know Java, then the language changed, then it changed again, and now knowing the language is irrelevant as you have to know the frameworks instead.
Keeping up with skills is sort of irrelevant when all the skills you learn are learned on your own. If someone can and has written their own language or OS, is it really necessary for them to know some temporarily fashionable language? Although maybe that makes people overqualified for the most common programming jobs.
Everybody knows software development is a "young man's game"? Did you seriously say that?
HELLS no, man.
First off: I've been programming since I was 8, but I was never a man, and I will never be a man, and I have never suffered under the idiotic delusion that this was ever exclusively a man's game -- young or otherwise. This is my game.
I am still programming at 40, and I assure you that youth offers no advantages over experience, either.
But, that doesn't stop me from mentoring. My interns may not be able to program like I do, but I'll give 'em every advantage I can. It's great to teach them some of those intrinsics that they don't get in school. That gives them some of the advantages an experienced developer, even if they're younger. This isn't a zero sum game. We all need good devs, so we should try to make everyone who is working with us better -- whether they are young or old. We all get better software, that way.
It's probably a reaction to all the ads that demand X+2 years experience with x year old tech. And the ads that say must be proficient in X, also a,b,c,d,e,f,g only to have the interviewer say OH, we only use X here.
They had to lie just to get past the HR filter in order to be interviewed.
"Grow Up"? Seriously? Some of us started coding at single digit ages. I "grew up" at age 17, when I was homeless and fending for myself on the streets. Patronize someone else, moron, you don't even know what life is. Ever seen someone's skull stomped in? You learn real quick what's actually important in life once yours is on the line. I learned real quick to have a plan B: Always have a contingency plan. Idiots without one are not, "grown up."
I've forgotten more languages than most have learned, but I'd be fine with folks not being considered programmer material at age 40 if they would hire from within for management positions. Instead of employing middle management drones with unrelated "business" (Secretary++) degrees give the folks with actual hands-on experience the job of managing the people in the job they actually know how to do. Face it: Those HR goons are morons, they can't tell good from evil, or else explain how the odd Napoleon-complexes and Micro-dictators in management even got there? If HR wasn't dumb as rocks they'd require demonstrations of skill, a coding test, not accreditations: Degree mills exist, fools; This is especially true overseas. Ah, but the that's getting to the real issue: Skill sets aren't what's really important to upper management... TFA's author isn't as "grown up" as they think.
The new platforms will keep coming, but the solutions will largely be the same. Now I can undercut competition via barging onto any new platform with my whole codebase faster than the other guy can tell you why the new language is "More Expressive". I just have to implement a new "platform runtime" for my meta compiler and then I can check off that platform as a capability and deploy ALL of my existing solutions on the platform since they're written in an even higher level language, and compile down into other languages. Sometimes this means we have to implement features the language doesn't have in the target language -- If I need a coroutine in C: When returning to the trampoline record the exit point. When calling into the coroutine specify the entry point to resume at. I generate a switch with GOTOs to resume from the next point of the operations (GOTO is very valuable, only idiots say otherwise; Look at any VM). Lambda lifting mutable persistent state out of the function scope has the benefit of thread safety. Since I treat comments as first class lexical tokens the compiler-compiler's output is fully readable and commented code in the target output language and following whatever style guide you want. (LOL @ brace placement arguments, what noobs)
See, experienced coders understand languages so well they aren't even languages to us, they're just problem solving APIs: The problem-space is independent of the implementation's solution-space. When we pick up new languages or platforms we're looking for, "How does this language let me solve problem $X?", but more importantly our experience lets us identify what solutions the platform lends itself to solving. Just because a new platform comes out doesn't mean it's more capable of solving every problem. Do this long enough and you'll get tired of re-inventing all your wheels in each new platform and just create a meta compiler, as I've done.
Fortunately I've always crossed off (and initialed) that employment contract paragraph that said everything I would create (even off the clock) would belong to the company: "I don't watch TV. I have several hobby projects I do instead and they need to remain mine. If you want me to give up my hobbies while working here you're going to have to pay me a lot more. Would you sign a contract to work somewhere that said you couldn't ever watch TV?" Protip: Most places have another employment contract without that clause, just tell them you make indie games or have a robotics / embedded systems project, contribute to open source in your spare time, etc. Make your hobby profitable. That way you can always have a plan B, and you'll have more leverage in any salary negotiations: "
If a fellow gets married, *then* his creativity and productivity plummets. His time is no longer his own. When I regard the fellows I work with, the guys over 40 who avoided marriage, or have been divorced for a while, are the "top guns" to put in U.S. terms. They have both creativity *and* a lot of experience, which makes them almost impossible to beat over the course of many months.
Well articulated, Ms. P., very well articulated, but /.'s parent company has been offshoring jobs for quite some time, no doubt the agenda behind this repitition!