Can Older Software Developers Still Learn New Tricks? 365
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."
One of two things. (Score:5, Interesting)
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.
Re:One of two things. (Score:4, Insightful)
Re: (Score:3, Insightful)
If my grandma can learn how to use an iPad at the age of 85, never having used a computer in all her life, then a 50 year old developer should have no problem picking up 'new tricks.'
If one grandma can learn an iPad, then there exists one old developer that can learn. If every grandma can learn an iPad, then all old developers can learn. Noticed the difference?
Re:One of two things. (Score:5, Informative)
I did sense that programming technologies were changing rapidly, and I managed to keep my hand in with all the 20-something coworkers by working very hard to study and learn and apply new things. It can be done.
Too often, I see folks debating the merits of various languages. During my career I learned a zillion of them. Not a big deal. The big deal is learning the concepts. Sometimes a particular language will embody a concept (such as objects) more clearly or more usefully than another. But once you grasp the concept, the rest is syntax. Once I was searching for a new job and an HR type rejected me because my CV did not show Visual Basic. When I did get a job a few weeks later, one of my first activities was helping a junior programmer develop some Visual Basic code. Although I had never seen Visual Basic code before, I became the "expert" because I could see the ideas and concepts beyond the syntax.
33, 40 is not "old". I am 70 now, and still get a kick out of reading
Re: (Score:3, Insightful)
Once I was searching for a new job and an HR type rejected me because my CV did not show Visual Basic.
This really irks me these days. Most job offers are buzzword bingo with a long list of "absolutely required" niche technology du jour stuff, none of which are particularly hard to pick up if you're a half-decent developer, but you will NOT get past the HR drones because you don't tick the boxes.
Re:One of two things. (Score:4, Insightful)
Found out later that class was made optional for later graduates. As the curriculum standards are lowered so will be the graduates ability to handle stress or workload
I'm 24, and I can verify this. Undergraduate level Comp Sci at a typical school is a joke these days. It is typically a thinly disguised Java programmer factory, since not enough schools make a distinction between computer science and software engineering. It's always bothered me that I was expected to just accept all of the low level hardware and software workings of a computer as magic, that it was supposedly a good thing that I didn't have to worry about them. I've invested a pretty significant amount of my free time studying those topics, and it's embarrassing how few of my developer peers (age-wise) have enough knowledge to have even a basic conversation about them.
It's great that I can use a language like Python to fire out a decent application rather quickly. But what happens when there's something you can't do with Python, or you need faster performance than Python can give you for a certain module? There's no excuse for a professional software developer to not be able to bust out a native implementation and give it a wrapper in a "nice" language.
is it really the same? (Score:4, Insightful)
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.
Re: (Score:3)
Do you have any recent technologies to cite as examples? Fp and async were both codified and well established in the 70s.
Admittedly, learning the new names for the same old shit, gets old faster than I do...
Re:is it really the same? (Score:4, Funny)
Re: (Score:3)
XML is a fine way for computers to talk to computers, but I should never have to see it with my own eyes.
Anyone who claims it's "Human Readable" has a different definition of both "Human" and "Readable" to the rest of us.
Re: (Score:3)
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.
Try giving an ipad to an 80 year old woman and you'll see how many interface ideas we take for granted right now.
For example, if you look at the list of emails on the ipad, the unread emails have a blue dot when they haven't been read yet. Reasonable enough, but it looks like a button that you can push to open the email. But if you push it, then the email doesn't open, the dot just disappears. Then the list of mailboxes keeps disappearing randomly.
Actually using the ipad for adult things is different th
Re: (Score:3)
Learning functional programming
Oh, you mean like LISP, from 1958?
or asynchronous server development
Oh, you mean like in "Theories of Abstract Automata", written by Michael Arbib, and published in 1969?
is not really on the same level as learning how to tap the right sequence of icons to get to the iPad games.
You're right. The first two things are so old they fart dust, like the grandmother who's trying to learn the third thing...
Re: (Score:2)
Better yet, reprogram the aircraft to land in India. And sit back and smile as the pilot says, "But the ILS says we're landing at LAX!!!"
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
No I can't, age has slowed down the mental process
Have you considered changing your diet, and maybe some exercise? You're not that old.
Re: (Score:2)
Re:One of two things. (Score:4, Insightful)
Re:One of two things. (Score:5, Insightful)
It's one of the benefits of experience that you know what to skip... although it's not always the same things for everybody.
Re: (Score:3)
1. Allow me to submit that it is not possible to learn a new language / development stack at a sufficiently deep level to produce "elegant" output in one day.
2. Yes, my time is that important. I'd rather spend it with my family. Or sleeping. Or pretty much anything than futzing around in a foreign dev environment "just because".
Burn out speaking here. (Score:2, Interesting)
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 prog
Re:One of two things. (Score:5, Insightful)
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.
I can't really disagree here, but I wouldn't say that the correlation be restricted to what is considered a 'tech hobby'.
I have known a number of men in their upper years that I would classify in the 'wizard' category, yet their hobbies included things like fly fishing, baseball statistics, flying small planes, etc. I would really consider any of these a 'tech hobby', but I would consider them hobbies that require a great deal of technical aptitude to also be a wizard in.
Keeping the mind sharp is the key. If you do that by observing local caddis fly species, tying your own imitations, nailing the presentation to the fish (including time of day, weather conditions, season, physical stealth), and ultimately landing a 22 inch trout on 7x tippet, I imagine that keeps you just as sharp in the day job than simply doing more day job like things in your free time.
Hobbies are meant to be hobbies for a reason. If you are an aspiring musician gigging at the local clubs to make your cash and you then spend your free time doing more of the same, but "just for fun", your musical career is probably not going to take you where you'd like it to.
Completely detaching from concepts related to your occupation/career during your "me time" is absolutely essential to having a long enough career to ever become one of those "wizards". If you're a programmer, and you spend your free time programming for fun, you'll certainly become a solid developer, but there are very few people who love code enough to be able to sustain that for 20 or more years.
TL;DR - going fishing is better than having a 'tech hobby'.
Re:One of two things. (Score:5, Interesting)
or maybe "Wizard" means "the guy who just quietly knows what to do and gets it done", no fuss, no drama, no "ooh we must do a total rewrite in Silverlight".
When you get to this status, you are a bit burned out - but only by playing office politics with ambitious morons, and playing chase-the-latest-tech-fashion. When you get to this stage you're more interested in making things work instead of just playing with the cool tech toys.
I know, I used to be a tech guy who did it all in the evenings, and wanted a job where I was just a techie doing pretty much the same... today, I don't give a fig about tech for its own sake, I just care about making the solutions to peoples problems.
Re: (Score:3)
I was much more of a tech hobbyist when I was younger. Then over time you just figure out that after a full day at work that the last thing you want to do is go home and hack some more code. Though there are occasional times when I yank out the compiler again, such as when I was laid off for a bit, or things weren't as stressful at work.
Re: (Score:3)
Or you work on something techy but not programming. I'd prefer to study electronics, physics, etc than program most of my offtime. I still like thinking in my time off, but I want to do it on a totally different topic.
Re: (Score:2)
Or a third -- they become software salesmen. I've never met an enterprise-level software salesman who didn't mention that he used to write in Assembler once.
NeXTStep Programming (Score:3)
Where's this bias? (Score:2)
I don't recall actually encountering it, not when I was younger, not now. (I'm starting to be on the older end of the spectrum, I think.)
Re: (Score:3)
In the headline.
Yes (Score:5, Funny)
Now get off my lawn
Old Dogs and New Tricks (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Yes, chances are the old dogs have already had to learn new trick a number of times, while the young'ns have so far only learned one way. GUI's, the web, and the like each have disrupted the development methods that came before them. Usually, some things are true improvements but other good ideas are lost - at least for a time.
The only problem I've ever had is when I know that a current technology is moving down the wrong path towards a dead-end. In this case it's difficult continue along the same path w
Older workers cost more. (Score:5, Interesting)
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.
Re: (Score:3)
They can command higher incomes based on their experience.
This calls the question that needs to be asked whenever this kind of discussion comes up. It is not so much can an old dog learn new tricks, but can new dogs learn the old tricks?
Put that in whatever terms you want. Will a new programmer know "this works well for this kind of problem", compared to "I can find a library that does this but I don't know/care how it works (and it really sucks at speed)".
Re: (Score:2)
Will a new programmer know "this works well for this kind of problem", compared to "I can find a library that does this but I don't know/care how it works (and it really sucks at speed)".
If the new programmer paid attention in his algorithms class, he should know the answer to that one just as well as the old guy..
Re: (Score:3)
It's exceedingly rare in my experience that anything from my algorithms class ever matters. Heck, these days performance seems to be dominated by lock contention, given the distributed nature of everything. The worst problem I see in young guys regarding performance issues is that they really want to trot out something cool they learned in their algorithms class, before they've even measured where the performance bottleneck is.
Re: (Score:2, Interesting)
Any other excuse for not hiring them is a smokescreen
Here's my excuse: Any old fart is going to have a deep network of contacts. If they have a good reputation, then they can use these contacts to quickly find new employment. So any old fart trying to find a job by replying to web ads is almost certainly a turd. I have hired plenty of old farts that I knew professionally, or were referred by people I trust, and have mostly been happy with them. I have never interviewed an old fart random responder that I wanted to hire.
Re: (Score:3)
Any other excuse for not hiring them is a smokescreen
Here's my excuse: Any old fart is going to have a deep network of contacts. If they have a good reputation, then they can use these contacts to quickly find new employment. So any old fart trying to find a job by replying to web ads is almost certainly a turd. I have hired plenty of old farts that I knew professionally, or were referred by people I trust, and have mostly been happy with them. I have never interviewed an old fart random responder that I wanted to hire.
I had an old fart come in as a contractor after retiring as a manager in a government agency. One of the best coders we ever had. I had another kid come right out of school, another great coder. We also had a slew of good, bad, and mediocre programmers, all with varying ages. Age has nothing to do with it.
Re:Older workers cost more. (Score:5, Insightful)
I'm not so sure about the contacts. I have recruiters ask if I know people who are looking for jobs, and to be honest, I never do. The ones I know out of work I also know aren't a fit (hardware guy for a software job, etc). Plus lets face it, I'm a techie, not a social butterfly, I don't keep up the contacts with all my past coworkers.
Re: (Score:2)
"Commanding a salary" means that employers *must* pay you your commanded salary because if they don't you will just work for someone who will, due the high demand for your unique skill.
If employers are able to lower demand for your unique skill, simply by spreading vague rumors, then I would say your command of your salary is weak.
Re:Older workers cost more. (Score:5, Interesting)
Perhaps a more important difference between young and old guys: if an old guy does turn out to be sucky, there's little chance of turning him around. With younger guys your chances of turning a mishire into a success are far greater.
Re: (Score:2)
That's not necessarily true. Not everyone needs a developer of the highest caliber - sometimes a junior or mid-level developer will suit your needs, not to mention your budget, perfectly. Another issue with older workers is that those higher incomes they demand could be as much as two to three times that of your junior/mid-level developers. That's not t
That's a stupid question! (Score:2)
Trygve would like a word with you... (Score:5, Informative)
http://en.m.wikipedia.org/wiki/Trygve_Reenskaug developed MVC when he was 49, and DCI when he was 78.
These older developers **read StackOverflow** (Score:3)
Nothing to do with age (Score:5, Interesting)
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!
or does that have more to do with qustions that (Score:2)
or does that have more to do with qustions that cover stuff that only comes up in classes and not real work?
Re: (Score:2)
>there's no reason you shouldn't be as capable of it at 80 as you were at 18 really.
I don't understand. The slightest googling of "brain aging" shows a tremendous amount of research in the inevitable shrinking of the brain, loss of neurons, and general decay of cognitive abilities. How can you say that . .
No one said that the rate of deterioration was so rapid that by 65 you can't solve simple math problems and by 75 you are a drooling idiot. I knew a local lawyer who held a place in the Guinness Book of Records for his late-life degrees. Last one received at about age 100, as I recall (he died at 102).
There are also a lot of claims made that one of the best ways to stave off age-related mental deterioration is to keep mentally active, and software design and programming should qualify for that, I'd think.
Fi
As a 38 year old software developer (Score:5, Funny)
I can say... wait, what was the question?
Re:As a 38 year old software developer (Score:5, Funny)
older!!! (Score:2)
Is this guy/gal a developer or not?
No, really, what is wrong with the world today? Why are you trying to connect "age" with "skills"? And just for the record, the wine becomes better with the age...
DO Older Developers Still WANT TO Learn New Tricks (Score:2)
Can a old programmer learn new tricks? Absolutely. Does he/she want to? Well.
Am I Too Old to Remember Answering This Question? (Score:4, Informative)
Ask Slashdot: Am I Too Old To Learn New Programming Languages? [slashdot.org]
Ask Slashdot: Am I Too Old To Retrain? [slashdot.org]
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>?"
Everybody can... (Score:3, Interesting)
Never trust anyone over 30 (Score:2)
you heard it here first
Can young developers learn old tricks? (Score:2)
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 ...
Re: (Score:2)
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 ...
To be fair, debugging Ruby on Rails with a soldering iron did strike a lot of us as a rather unconventional approach...
Unable or Unwilling or Unmotivated ? (Score:2)
It seems to me there are 3 types of programmers ...
1. Unable,
... with respect to learning.
2. Unwilling,
3. Unmotivated, or
As you grow older there are more calcium deposits in your brain which is where the term "fossilized thinking" comes from. You can't help those unable to learn or unwilling. These are where the stereotypes come from.
Now as to the last group ...
They say the mind is like a muscle -- to keep it in top shape you need to exercise it. If old programmers are n
Re: (Score:3)
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 t
Re:Unable or Unwilling or Unmotivated ? (Score:5, Insightful)
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)
Re: (Score:3)
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 kno
New Tricks? (Score:3, Insightful)
Well crap (Score:2)
Betteridge's Law is wrong for once.
That said, I would argue, while ageism is *mostly* an aversion to spending money hiring pros who know what they're doing when they could hire novices for cheaper, coupled with an unassailable feeling (perhaps justified, perhaps not) that those older, more experienced people would be so offended at making less than ridiculous money that they would rather be unemployed than making less than what they did last time they had a job... it is also unarguably true that just becaus
It's not about age. (Score:5, Interesting)
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.
Re:It's not about age. (Score:4, Insightful)
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.
Tex was written in 1978. There aren't many people today who write code of that quality today.
Good programmers write good code in any language; crappy programmers write crappy code even if they unit test every line of code in an OOP system using MVC (although the code will be less crappy than if they didn't use those).
Re: (Score:2)
The problem is that programming was a rapidly changing field up until a few decades ago.
Huh? Programming has never been a static field, but I think most people would argue that it has been changing at an increasingly rapid rate, just as all technology has. In the 1960s, the move was from assembler/autocoder to FORTRAN/COBOL/PL/1. In the 1970s, more online systems, 4GLs and Structured Programming and punched cards began to be replaced by terminals. In the 1980s, PCs, GUIs, OOP, primitive IDEs, MVC. In the 1990s, RDBMS's started popping up almost everywhere and were no longer exotic specializati
Re: (Score:3)
Re: (Score:3)
> maybe the only thing added to engineering the last 10 years is unit testing.
Hmmm. There was an IEEE standard for unit testing in... 1987. A quarter century ago.
"Those who don't learn from history are doomed to repeat it."
30+ Years of Coding (Score:2)
I fall into the old fart 'get off my lawn!' camp. I'm in my 40s and have been doing dev since I started 6502 Assembler on my C-64 way way back in the day.
To be honest I find the opposite of this article to be true... this old dog has no problem learning new tricks. I'm writing my best code now, and every day I get better. I can draw on decades of experience and use that to quickly assimilate new languages, data formats, communication protocols... bring it on! I feel quite confident in my ability to lear
From a Systems person... (Score:3, Insightful)
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
It's not an overnight change (Score:3)
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.
yes (Score:2, Insightful)
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 (
My theory (Score:2)
Everyone has a theory, so here's mine.
The question is whether one has demonstrated the ability to make paradigm shifts: unstructured to structured, structured to OOP, 3GL to SQL, imperative to functional or dataflow. A gray-hair stuck maintaining COBOL or FORTRAN for the past 40 years has not demonstrated an ability to make a paradigm shift. In contrast, a gray-hair who has demonstrated past paradigm shifts should be presumed to retain the capacity for further paradigm shifts, until proven otherwise -- an
It's great to be old (Score:3)
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.
Old Geeks (Score:5, Interesting)
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.
There are no new tricks. (Score:2)
I remember the young ones say, "make a list or make vector, it is cheap, we do it all the time" when I finally decided to give up the ghost on my own klib (k for Knuth) for containers and switch to STL. Well, they were talking to the guy who obsesses over the number of square roots it takes to find the area of a triangle. Well, I wrote my benchmark code and came back with, 1 addition = 1 unit, mult 3 units,
Experience vs. Technology (Score:2)
I don't think age really has all that much to do with whether someone is an effective programmer, but rather the types of experiences they've had over the years and whether they've learned from them. This goes hand in hand with keeping an open mind and being open to criticism, and even admitting mistakes and failure when appropriate.
Debugging is the most important skill that older programmers often excel at. They've run into similar problems in the past, and those who've learned from those problems and
Cynicism? (Score:2)
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).
What is the nature of brain aging? (Score:2)
Latest research says brain aging is most commonly a function habitual use of pre-existing neural pathways to the exclusion of growing new ones. This is what "Couch Potato Syndrome" does. Most of the aging programmers I know, are always looking at new tech. They have a burning curiosity about the universe in general and about how to keep a razors edge honed on their chosen craft. Most of these people have shockingly large libraries. Many read a slug of journals. Many game. Many have wildly eclectic and diver
Older is wiser? (Score:2, Interesting)
Older Is Wiser: Study Shows Software Developers’ Skills Improve Over Time
This is a non-sequitur. Even if it is true that every single programmer becomes better with age, this doesn't mean older programmers are better than young programmers. Younger programmers can (and actually do) get better faster, because they are educated in a time with better tools and methodologies. The bar is higher now than it was before.
There were some really smart mathematicians back in ancient greece, like euclid. Now we teach highschool kids what it took Euclid to figure out over the course o
Often, they cannot (Score:2)
Often, older developers cannot learn new tricks for one simple reason: They know most of the tricks already, in some form or another.
It has been my experience that older developers don't just adapt just as quickly to a new technology, they bring in knowledge from other areas of experience that a younger developer might not consider.
This isn't to say this is true of all older developers - not even close: there are as many dinosaurs as there are greenies fighting above their weight class. But, as so many will
Re:Of course not (Score:5, Insightful)
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. :)
Re: (Score:3)
Don't forget to add things like LISP, snobol, prolog, Pascal, Modula-2, SML, APL etc. :-)
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
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 c
Re: (Score:2)
I'm sorry kids, my mind wonder
Re: (Score:3)
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.
Re: (Score:3)
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
Re:You can't discriminate based on age in the U.S. (Score:4, Insightful)
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.
stackoverflow isn't right (Score:3)
Indeed, I suspect stackoverflow may not be able to measure the information we want to know.
Re: (Score:2)
Re: (Score:3)
Indeed, I suspect stackoverflow may not be able to measure the information we want to know.
Stackoverflow is committed to quick, specific answers. One of the things you get from experience is a lot of the same thing over and over again in minor variations, and your answers are more likely to be broader and less suited to the stackoverflow ideal.
Re:old people have higher Health Care and don't 80 (Score:5, Insightful)
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.
Re: (Score:2)
Give an example of a "trick".
C++11 lambdas.
Re: (Score:2)
Lambdas are indeed "tricks" that IMO are syntax candy (in C++), can be a bitch to debug, and add little value. But then again after 20 years of C+_ coding and inane debate (like this one) I feel this way about C++ in its entirety lately.
I don't feel this way about anonymous functions in general - I just think the C++ implementation is hopelessly bent.
Re:what tricks? (Score:4, Insightful)
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.
Re: (Score:3)
CaN brain-dead numbnuts quit quoting "Betteridge's law of headlines"?
Well by applying Betteridge's law the answer is obviously .... Oh wait!