Slashdot Mirror
Can Older Software Developers Still Learn New Tricks?
An anonymous reader writes "There's a persistent bias against older programmers in the software development industry, but do the claims against older developers' hold up? A new paper looks at reputation on StackOverflow, and finds that reputation grows as developers get older. Older developers know about a wider variety of technologies. All ages seem to be equally knowledgeable about most recent programming technologies. Two exceptions: older developers have the edge when it comes to iOS and Windows Phone."
Older developers are always one of two things. They are invaluable wizards who have tons of experience, adaptability and know all the new technologies, or they are completely burnt out and useless. There is almost no middle ground. There is also a strong correlation between interest and hobbies - if they are doing techie things for fun, they will usually be in the wizard category. If they have just been doing the same old job for decades, and do few tech projects for fun, they will be burnt out.
Now get off my lawn
If your old dog can't learn any new tricks, the chances are he couldn't learn any tricks when he was young as well.
They can command higher incomes based on their experience. They are harder to exploit, again because of their experience. Their health insurance costs more (more a product of poorly managed health care policies that are often beyond the employers control).
Any other excuse for not hiring them is a smokescreen, or worse, an attempt to stigmatize them to drive down the price that their experience can command.
http://en.m.wikipedia.org/wiki/Trygve_Reenskaug developed MVC when he was 49, and DCI when he was 78.
That depends on the individual. I've known people in their 20s who were already set in their ways, and people in their 70s who were still open to new ideas. It's got nothing to do with age as such - it's entirely a state of mind. If you keep using your brain to learn new things, there's no reason you shouldn't be as capable of it at 80 as you were at 18 really.
I'm 55 and i'm studying science at university. I'm having less difficulty than some of my 20-something uni mates. I taught myself PHP, HTML, CSS, and JavaScript, a few years ago, so i could work as a web developer for a while. I taught myself Java in the uni break last year so i could play with developing Android apps.
If you use it, you don't lose it!
I can say... wait, what was the question?
Yeah, this old fart knows Cobol, Assembly, C, C++, Java, a little C# and several other languages. I enjoy when you younger guys come to me for help because you can't read a log file, resolve a memory leak, write a test plan up, or optimize your SQL. :)
No. No I am not. For reference see:
Ask Slashdot: Am I Too Old To Learn New Programming Languages?
Ask Slashdot: Am I Too Old To Retrain?
They should have a lot of the bland "buck up" responses alongside the "outta my way I know everything" youngsters.
Also, to more quickly expedite this process, I prefer your story submissions in the form of "Ask Slashdot: Am I Too Old To <X>?"
My work here is dung.
I know 20 years old guys who can learn nothing new, like lazy teenagers. The question is biased. Of course, there is a biological neural decay with age, but like any other muscle, the brain need exercise, and that don't depends on age but on attitude about life. If you like and enjoy to learn new things, you will enjoy that the whole life, that's a fact.
I think a better question would be, how often does something genuinely new come along?
Employers can't use a correlation even if there is one, so stop worrying about it. If learning new tricks is important for them they can ask for recent examples during the interview or test the ability directly with a question.
Don't worry. There isn't a shred of discoverable evidence that your age had any bearing on our decision to choose somebody who seemed like a better fit for the FooCorp team.
Learning functional programming or asynchronous server development is not really on the same level as learning how to tap the right sequence of icons to get to the iPad games.
“Common sense is not so common.” — Voltaire
The problem is that programming was a rapidly changing field up until a few decades ago.
It simply wasn't possible to be a good programmer (by today's standards) in the 1970's. You could be a good programmer for the time. Many of those people have kept current with new design methodologies and many haven't. The ones that haven't kept up, continue to think of themselves as badass programmers who know everything, when in reality the world has just passed them by.
It is not that old people are bad programmers. It is that people who learned how to program before the field of programming really matured tended to have "stone age" tools and didn't always keep up to date. As time passes, the "old programmers" are changing. I am 33. People considered "old" are not even that much older than me. They had a much different experience learning to program. They didn't learn to program in "the wild west" like some of the really old programmers. Many received formal training at universities where they learned a lot of the theory of computing. They also benefited for learning in a time when more was known about how to program in a way that minimizes mistakes and increases scalability, maintainability, etc.
old people have higher Health Care and don't like pulling 80+ weeks.
Or even 40+ weeks. And don't need to because they tend to do their work more efficiently as opposed to galloping odf enthusiastically in all directions. Ultimately producing stronger, more maintainable code. By way of substantiation, note that the typical European worker at ~37 hours/week is typically as productive as an American or Asian worker supposedly putting in way more hours. The equalizer is, Europeans tend to plan better and waste less time.
BTW, note that being an older programmer does not obviate the possibility of having a young lover. Far from it. In work or love it's about keeping your stamina up: take care of your eyes and your body. Treasure your enthusiasm for life. Keep your mind active and never stop learning. The rest just falls into place.
When all you have is a hammer, every problem starts to look like a thumb.
I'm not a developer per se. I fall into the new DevOps (god, I hate that lingo) area, which is a combination of systems administration and tools developer. We write a lot of code these days, but it's all for automation, thus, it's all over the board. I also do Release Engineering, which gets one a lot closer to the coders.
The biggest thing I see that might feed this perception of Old = Unwilling to Learn is that the older I (and my peer friends) get, the more resistant we become to "fads". After almost 20 years in this business, I have one of the larger breadths of technical knowledge than anyone I know (I'm a generalist, not a specialist). I've seen and used a vast variety of tools and languages, and am still picking up new things which pass a cost/benefit analysis.
The key here is that large chunks of Programming is cyclical fads of "hot" tools, languages, and frameworks. The problem is, from a systems standpoint, that these fads last 5 years of so, and then something else comes up. Which leaves me with a massive headache because of all the different languages and tools people wanted to use at that particular moment in time.
I'm going to pick on Ruby right now as an example. It's the hot systems (admin) programming language, with several major tools both written in it, and using it as the DSL. There's also a major push to use it for much of the automation code. The problem is, Ruby sucks for IT people. It's very unlikely that they know it, and it's quite a bit different than any other commonly known IT scripting language. And, the killer thing is that it doesn't solve any of the typical problems for systems folks better than Python or Perl. Yet, it's being pushed on us all over the place, because it's what's hot right now.
Things like that actually hurt my job performance, because it adds another language that I have to commonly use in my daily workload. And that is a recipe for problems, because, I don't care how hotshot a programmer you think you are, major context switching in the human mind is difficult and error-prone. Anyone is far more likely to make mistakes if they are forced to simultaneously code in 2-3 languages at once, or try to look at things that are written as such. I my case, that would mean I have to try to debug Chef recipes (written in Ruby), with Linux bash and Windows Powershell scripts being called, and using a perl or python (or lord knows, a Grails setup) all at the same time. It's a nightmare to write good code in, let alone debug.
The root I'm getting at here is that resistance to new things from experienced people is usually well-justified, because we've already come up with solid, maintainable, and efficient ways to do what the "fad" claims to do. In most cases, the fad does work well, it just doesn't work any better than what we have now (or, at best, only marginally better), and certainly isn't mature enough to satisfy all the other requirements that programmers forget about when choosing languages/frameworks.
It just boils down to experienced folks are very familiar with the "standard toolchest" of what really works, and there's a high barrier to entry for new things to be considered worth-while to learn. For me, the aforementioned Chef passed that barrier. I can't stand Ruby, but the Chef system works well enough (and significantly better than) the prior existing configuration systems, so I learned it, and I'm better for it. Capistrano, however, didn't make the cut, because it's also in Ruby and isn't really any improvement at all over existing deployment setups.
Systems people are just more conservative than development when it comes to tools and language uptake, because we have to be. Our requirements are fundamentally different than programming, which means that we tend to look dimly on the "popular-at-the-moment" things, which can be seen as a reluctance to learn. It's not; it's wisdom, and something that I find annoyingly lacking in both management and development.
-Erik
amen. The thing with old guys is that we've seen the fads come and go - did you jump to learn Silverlight, Linq2SQL, etc? Yes, well, fool you. The old dogs take their time to see if a tech is actually any good and worthwhile before going crazy for it - unlike a lot of younger guys who seem to think that if they haven't completed a project they can move to a different tech and then fail to complete that too, but without anyone noticing!
Its the same with a lot of stuff- .net moves so quickly that no-one really became a true expert in it, as soon as you learned one tech, it was scrapped and a different one with the same name and different version came along - ho hum. The old guys remember when you made things properly first time (or, if a MS dev, waited for version 3 before taking notice of it)
A faculty advisor mine really loved his work. He never retired, worked until he died at age 93.
His university tried to force him into retirement, cut his lab space and other wise tried to hassle him. He was 70 at the time.
In his early 70's he published some work on electrospray mass spectroscopy (ESMS) which was applicable to the analysis of proteins.
ESMS led directly the development of protease inhibitors and was a key part of the founding of the science of Protenomics.
That led to his being awarded a share in a Nobel Prize in Chemistry in 2002. He was 85 and by then had moved on to another university with less discriminatory attitudes towards older faculty.
Lambdas are indeed "tricks" that IMO are syntax candy
All programming languages are "syntax candy". Here's the problem: using one language over another can only speed up or slow down your performance by a constant factor. But using a language who syntax encourages better algorithms will often present opportunities for O(n^k) improvements in the code (where k>1). So your "syntax sugar" is often worth it even if it means using managed environments or bytecode sand boxes (because the constant factor slow down will be insignificant to oft-present algorithmic speed up). That is not to say that bad coders won't code badly in all languages. But programming is largely an exercise in attention span management. Anything which facilitates that (aka syntactic sugar) will present opportunities to good coders to be good. Oh, and in case, you are getting ready to get on a high horse, of course, I know what lambdas are.
I feel this way about C++ in its entirety lately.
You are not a programmer. You are a code monkey. The most value of the code comes from how quickly it can be understood by a human. You've heard that before. You laughed it off. It's not because they were wrong. It' because you didn't get it.
Any guest worker system is indistinguishable from indentured servitude.