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.
All that programming on NeXT finally becomes useful.
Now get off my lawn
In the headline.
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.
There are two selection criteria: these developers are older, and they participate at StackOverflow. So, they're the guys who sick with programming, not management or retirement, and who "get" social media, at least SO, and are developer community oriented. This is a select group of individuals!
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 mean, them young whippersnappers seem like drooling retards when I break out my trusty old soldering iron. You know, for debugging like back when bugs actually stung ...
For the sufficiently clueless, even trivial applications of common sense are indistinguishable from wisdom
I think a better question would be, how often does something genuinely new come along?
I fall into the burn out catagory - I guess.
I spent over a decade working on applications and OSes. Then to keep up with tech, I would go home and program some more - and I was ruthless about trying to incorprate any new tech into my job so that I could have paid experience on my resume. I was working what comes to 80 - 100 hours a week programming.
I can't stand to program - let alone for fun, now.
I'll do it to solve a problem and even enjoy it - the solving the problem. But to program for the sake of programming? NFW.
I'm pushing 50, btw.
Of course, I'd LOVE to do something else, but trying to move out of development or anything IT is proving to be difficult for many reasons. One of them is that people insist on pidgeonholing you.
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.
Don't forget to add things like LISP, snobol, prolog, Pascal, Modula-2, SML, APL etc. :-)
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
Indeed, I suspect stackoverflow may not be able to measure the information we want to know.
“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.
I was in the unwilling category. Being a highly skilled and comfortable Delphi programmer feeling at home with the win32 API I resented the idea of having to give up my comfortable tools and in discussions I'd use any argument to win. Eventually, everyone around me had moved. Mostly to dot net. Although I resent dot net now as much as I did then, I did realize that I needed to move to new technologies or become irrelevant.
That was over 5 years ago. Since then I embraced most technologies and love them for the same reasons as I used to hate them. I still think today's tools are backwards compared to the highly integrated IDE's we used to have. Especially for web applications but I am having fun again and now I am more open to new ideas and technologies.
But having said that, I probably don't run as fast to the next shiny thing as young developers do.
I know people in their nineties that are still sharp. If you manage to remain in the technology current and open your mind as a software engineer, you can perform your craft till you die.
Most of the 3GLs and a fair number of 2GLs, the entire lineage of databases and indexed file systems.
The whole experience of learning new languages came to a stop when I found I couldn't learn Hindi.
Do not mock my vision of impractical footwear
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
Older developers have plenty of time to look at new technologies and decide if they want to have anything to do with them. They also have enough weight in the company to pick and choose jobs that they take. Many young developers, raised on Python and Perl, are not even capable of doing those jobs - such as writing the assembly code for a small 8-bit MCU. The rift between that code, and code that implements some Web 3.0 JS thingy (that is all the rage, of course!) is huge. I do not do web programming, and I do not expect to ever do it - simply because it doesn't interest me, and I don't like how it works anyway.
If an old developer is unwilling to change, there is still plenty of work for him left. I work with hardware and low level software; these methods haven't changed for a long time (since 8080 stepped into the game.) But I'm using WPF for all my GUI needs these days, instead of (historically) OWL, MFC, Qt, and such. I gladly went with that change because I liked the result.
My experience in hiring programmers of all ages is that older programmers are more reliable and less management overhead. They tend to be less prone to take risk (experience does that to you :) Generally more productive but not necessarily pushing the envelope. That is, of course, a gross generalization. There are some old dudes who rock.
Young (or rather, inexperienced) programmers tend to offset any productivity with management headaches, bad risks, missed deadlines, etc. But they offset that with a (charmingly) naive push into the novel (mostly due to ignorance). Again, a gross generalization. There are some younger dudes who "get it".
Since programming is still not proper engineering but more of a craftsmanship, a combination of both older and younger programmers makes an excellent combination. Younger pushing the older by questioning assumptions. Older training the younger, by bringing perspective and discipline.
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)
When I was younger (twenties and early thirties[1]) I had to work hard to learn something new, because quite often there were fundamental concepts, tools, or processes that were completely new to me. Nowadays when I learn something new, there's usually something pretty similar I already know, and while some of the practices will change (hopefully for the better) the basic ideas are largely unchanged. JSON? Yeah, a lot like XML or HTML, oriented towards JavaScript. Git? Take all your regular VCS concepts and add the concept of a complete repository on every developer's box. NoSQL? Think hashtables...really, really big hashtables. Virtualized OSs? Kind of like multi-tasking -- only your tasks are operating systems instead of applications.[2]
All four of those technologies have become prevalent within the past few years, and it took me no more than a couple weeks to grasp the fundamentals of each and start being productive. Sure, I spent time Googling and reading documentation, but I also didn't write code that would be a great candidate for the DailyWTF.
So yeah, I love being an old fart in his 40s. You can hire that twenty-something kid for half my salary, and he might put in more hours (most weeks I top out at around 45), but I can tell you I'm way more productive today than I was in my 20s. And I can learn those "new tricks" just as well or better today.
Thomas
[1] That's when I was in my 20s and 30s, not during the 1920s and 1930s. Now get off my lawn dammit!
[2] Yes, those are huge over-simplifications, to the point they kind of make me cringe, but the point is these new technologies all have parallels to something older.
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.
I don't consider myself to be an old fart, yet I know how to do most of the things you mention there.
I know a tiny bit of COBOL; just enough to hate it. I could muddle through assembly if I had to. (True story: In college, my Intro to Computers instructor forced us to read and write System/360 machine code by hand.) C and C++: I'm rusty, but not incompetent. Java, C#, and SQL (any dialect) are my bitch. Log files don't terrify me; grep was made for a reason. Memory leaks are a pain, but not insurmountable. Test plans are for people who actually test (just kidding!).
Age: 33. (Not old, dammit!)
If you are over 30 and a programmer, your walker will be arriving shortly. Security will be on hand to escort you out.
Sometimes older workers are more cynical because they are better at recognizing BS and buzzwords. While this can be useful, it can also rub executives wrong because they don't want to hear the fact that their shiny new click-a-matic toy will crash the planet and kill puppies.
Telling bosses what they want to hear does have value career-wise (as long as you plan a clever CYA when things go south).
Table-ized A.I.
Ain't that the truth !! Glad you got modded up. It seems like every tech gets re-invented every 20 years by somebody trying to sell you their silver bullet. Microsoft is particularly bad with their 3 letter acronyms every 5 years. That is not to say they don't have a solution, but there are ALWAYS edge cases and assumptions that need to checked before I'll "buy" into it. Namely is your solution:
a) scalable?
b) robust?
c) efficient?
d) not over-engineered?
e) proven?
f) using industry standards?
g) Do you know when and where it _doesn't_ work?
The last one tells me how well you understand the problem, solution, and domain. If you haven't thought about ALL the issues your solution is probably half-baked. It is perfectly fine that a solution is not "complete" as long as you know both the pro's and con's of a solution. Programmers need to make tradeoffs every day. Some are acceptable, some are not. Do you know the difference on how to prioritize them? ;-)
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.
Please provide a source on this. I'd like to read the source of the studies showing this.
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.
I'm not as senior as you, but a lot of what you say rings true with me.
The single biggest advantage of having an experienced engineer is they have seen the many mistakes over the years that shouldn't be repeated. Lots of the hot-shot but lack-luster younger engineers I've seen are so caught up in the areas they are talented they ignore the lessons they can learn from the older. I'm still on the young side, but I wouldn't be where I am without the many mentors I've had.
Other than the philosophy of younger think differently (for good or for bad), some management can be eager to benefit from young, eager engineers with less family responsibilities.
It would be easier to teach new programmers the old mainframe environment we used to use than the new Java environment that replaced it. Not that Java is inherently difficult in itself. It's just that the newer system had to reinvent so many wheels that were performed "under the hood" on the mainframe that the application itself became a lot more complex. On the older system, applications programmers could concentrate on the application and not networking, file logging, security, etc.
One of the reasons cited for moving off the old environment was a lack of people with mainframe skills. Mainframe isn't a skill ... it's just an OS, editor, set of languages, and programmer environment like anything else, and simpler than many.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
I try to keep up with the knowledge requirements. But what is valuable about older programmers is judgement, AKA wisdom. The kid fresh out of college knows how to record the number in a database. But he does not know WHETHER to record the number in the database. Do you store it or recompute it? Does the unit of measure change? Do you store a change history? Is the number valuable enough to the company to pay for data entry? You can fit the numbers onto a small screen, but will anyone want to read them?
I recently had a manager ask for a report, and I pointed out to him that his request would show him fifteen thousand numbers. Fifteen thousand numbers are effectively useless. So together we figured out what he really wanted.
Colleges, and reference manuals, can teach you how to code. Only experience can teach you whether to code, and when to code, and what to code, and what not to code.
CaN brain-dead numbnuts quit quoting "Betteridge's law of headlines"?
Well by applying Betteridge's law the answer is obviously .... Oh wait!