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.
If you could, you wouldn't be asking this question every three months on any site desperate enough for clicks. Advice: hang up you keyboard when you get found out, because if you know what you're doing, this is a moot question.
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.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
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.
I learn something new nearly everyday. I learn more and more my boss is a clueless asshat, and if I didn't stay current with programming and technology I wouldn't be able to continue to work. Being flexible, knowing what I know, always willing to learn more keeps me employed. Because sooner or later when the "IT Director" is found out for the ignorant fool that he is I'll be in a position to take over his job. That or I'll find a new job and sit back and watch the company implode.
Carpe Scrotum - The only way to deal with your competition.
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!
Yes, there are a lot of excellent older developers who have built up a good reputation and have a network of contacts that allows them to work whenever they want to work.
And there are a lot of really crappy developers who were given a a chance when they were young by managers who hoped they were diamonds in the rough, but it turned out they were just crappy developers. Once those developers got old, managers pass them over for younger prospects who may still potentially show some talent someday.
If you can't find work as a developer right now, it's time to think about a new career.
Is it me, or does an article like this seem to find it's way ontol slashdot on an almost monthly basis?
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?
The question is wrong. The real question should be:
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...
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. :)
Can a old programmer learn new tricks? Absolutely. Does he/she want to? Well.
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.
you heard it here first
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
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 not motivated to learn then I have to ask why?? Have they mastered THAT much of programming that they have exhausted all the interested topics?? I would argue that there are SO MANY interesting topics in computing that any programmer worth his salt should _easily_ be able to find enough interesting problems to solve as they get older. That's one of the benefits to comp. sci. -- there is always something neat to learn. Nay, the human condition -- you will NEVER stop learning (unless you become close minded.) Everything from bit-twiddling tricks to optimizing multi-threaded-multi-core programming with "Big Data" should keep any reasonable programmer motivated to learn. If not, they they are probably either burnt-out or crappy programmers.
The advantages older programmers have is that they have a much wider experience to draw upon so they don't make the same dumb mistakes over-and-over as the youth. i.e. When you have badly designed languages like Javascript that do NO type-checking on misspelt variables you use better tools to prevent the mistakes from the 80's Basic.
Another advantage is that older programmers don't have to focus on the tediousness of syntax and can focus on the higher level algorithms.
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. :-)
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!)
As usual, follow the money. The "knock" on older programmers and engineers isn't about capability, it's about cost. Experienced engineers want to be paid commensurate with their experience. Corps don't want to do that.
Corps find themselves faced with a choice. Would they rather do something right the first time (by using experienced engineers), or would they rather file to fit and paint to match (by using inexperienced engineers)? Corps overwhelmingly prefer the latter, at least in the USA. Thus the constant lies in the press about the lack of engineers in the USA (when what they mean is, the lack of *cheap* engineers), and the constant attempts to get cheap engineers from overseas using H1B visas. All while experienced engineers in the USA see continued high unemployment.
Follow the money people. Follow the money.
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
Or SPL, BASIC, Batch (DOS), Fortran...
I'm still relatively new/young in the world of software development - late 20's, 5 years of experience, but I've seen this argument come up regularly and the simple fact of the matter is that there is no difference between older/experience software developers and any other career. You have to: migrate, mutate, adapt or die in any career. If you get set in your ways in any profession and don't adapt with what comes your way you're going to fall behind and become useless or dead weight. I talk to the older/more experienced developers I know all the time because they've had experiences and insights that I haven't.
The question is whether young software developers can learn old stuff that has been ignored for decades and rediscovered only recently.
Ezekiel 23:20
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 because something is "new", doesn't always make it "better".
Sometimes it *does* make it better, granted, at least for certain things (managed languages are fantastic, for instance - I never want to go back to c++ if I don't have to - but I am aware that if I ever want to program a chip with a tiny sliver of memory, or do anything that requires to-the-wire speed, or write a compiler or an OS or a driver, a managed language is not the right tool.) But sometimes there's just no point in a new technology at all except to be buzzword-compliant. So why would people learn them, unless they're bedazzled by buzzwords? Probably less experienced people doing that, as far as programmers go (pointy haired bosses will do it at any age. :p)
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.
What is old? Is it over thirty? Over forty? Over sixty even?
no, I don't have a sig
I'm of average,(almost), intelligence; but what doesn't get old is when junior,(a Stanford Grad no less), comes up to me and says, "the manual says it does this, but the same code in my project doesn't do what the manual says it should." Fun times, fun times. Then the horror in their eyes when I say, "oh? just do this then" They plead, "that's not written anywhere!" And the abject anger that occurs when I suggest she/he should go back to school and ask for their money back.
I'm sorry kids, my mind wondered; it won't happen again.
Based on my experience (26 years in the software development industry), I am unconvinced that "old" programmers are any less likely to change - I have seen plenty of young programmers unwilling to adapt to new technologies. I think the more important answer lies with the attitude and disposition of the programmer than their age.
I am ready to admit that I might be biased since I fall into the old category a lot more easily than the young category - but I am comfortable with my own subjective conclusion on this issue ;)
KK4SFV
I've been a programmer for over 30 years. Starting with desktop applications and slowly migrating to web applications over the decades. And although I've slowly moved up into management (now at the VP level), I keep my skills honed and sharp to the point where I still help directly drive development projects all the way down to the code level which is still my passion. The one thing I've noticed over the years is that I no longer learn new tricks just because they're new. I don't have the cycles to learn fads. But I constantly watch new emerging technologies and dive head-first into new tech that looks promising and really makes sense to me. I'm much more skeptical about new things. Sometimes I'm right and sometimes I'm wrong, but when I'm wrong I get the play catch-up instead of wasting my time.
What's up with this box everyone has to think inside of or outside of? Why does there have to be a box?
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
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 learn most new languages in relatively short time because I've seen the same functionality done so many times in other languages I know how the code should flow. That to me is a tremendous asset.
There are only 10 kinds of people in the world. Those that understand binary and those that don't.
absolutely! i'm a young adult, myself, and worry about losing my ability to learn as much as i want to in life. some good advice i've been told: at work, you push the limits of what you are what you're good at, and at home or on your off time, you keep yourself engaged and iron out what you have a hard time with, through your various hobby code and projects
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.
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 -- and furthermore should have a "seen it before" trove of experience to bring to the table.
Give an example of a "trick".
C++11 lambdas.
When all you have is a hammer, every problem starts to look like a thumb.
or does that have more to do with qustions that cover stuff that only comes up in classes and not real work?
A qualified OO computer programmer worth his weight can pick up new languages and be proficient with it in 1-2 weeks. Most every language shares similarities that are easy to understand and skills are transferable.
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.
Is there really such a thing as a 'new' trick? Those really experienced programmers should already have seen most tricks and the new tricks are just the old tricks repackaged, or the old ways that were forgotten. Given enough time, the old tricks become new again.
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.
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, sqrt/exp 7 units, sine/cosine/log 14 units, atan,acos,asin, 30 units, and ... std::list.pushback() 180 units, std::vector.insert() 180 units (amortized). Abandoned my klib and am using STL now, but I know how expensive these are, and often I recalculate data instead of hashing them or saving them in a map.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
If it was, youngsters would never be employed.
Salary. A decreased willingness to take shit. An increased desire to spend time out of work. Younger managers feeling uncomfortable managing older workers.
These are the issues.
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 mistakes are quicker to spot the issues even with newer tools and technologies.
Perhaps it's better to ask if people are set in their ways or open minded to learning rather than how old they are.
I do not fail; I succeed at finding out what does not work.
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.
I am very small, utmostly microscopic.
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.
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 diverse personal lives. None of these things tends to result in the mummification of the human brain attributed to the normal processes associated with the average citizens aging.
Its completely arguable that our chosen lifestyles are the perfect means by which to ensure healthy and productive brain function into extreme old age. Add to that the growing use of nootropics and other brain enhancing technologies by mind workers and I can easily imagine mentally agile and productive engineers in their 80s and 90s. There was a study on human productivity that talks about two markedly different trajectories in math and physics. One group shoots to prominence in their 20s making world changing discoveries and solving insanely hard problems then slowly fading over time as they never reach that singular height again. Call them shooting stars. The other group, start off slower, but keep rising, in fact they continue to slowly but surely ascend their entire lives and by the end of their careers have achieved remarkable productivity right up until the end. Call these folks comets.
By the nature of our work, I suspect most software engineers are comets, or they find other lines of work that inspire them after 20 years. You either love intellectual puzzled or your don't. There is no good evidence or logic pointing to older engineers being less in any significant way. In fact the evidence is to the contrary.
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 of his entire life. Is an average high school kid a batter mathematician than Euclid? No not really, but that's only because we put everything into historical perspective. An average college kid can do calculus, which was invented 2000 years after Euclid died, and in that sense an average college kid is better at "doing math" (not necessarily discovering math) than Euclid, simply by virtue of having learned math in a time of greater knowledge.
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 point out, you can't generalize.
I'm turning 40. I need to believe this.
This is what experience is. Enough experience to realize that manuals are merely rough guidelines instead of precise documents. Wise enough to accept that you have to find a workaround. Enough times dealing with this that you have a larger bag of tricks to work with when doing the next workaround.
If the reputation scores weren't normalized by how long people have been active on the site, it invalidates the study's performance measure. It takes both good answers and time to accumulate high reputations.
One of our best developers just turned 60 and he has only been with us a couple years. He and I are working on a high-profile project together and it has been great. I am the same age as his son. He has no problem picking up new technologies. Spent a lifetime (decades) on a C++ compiler team and now we do bioinformatics/sequence analysis/scientific programming -- and he taught himself a ton about genetics, DNA sequencing, and short read alignment.
Currently I am a "senior" developer by title (I have been for 6 years or so, since I was 27). I was a younger guy on the team back then. We hired an entry level guy last year straight out of his undergrad. He makes me feel old. He was probably in diapers when Nevermind came out :)
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 (in C++), can be a bitch to debug, and add little value
You know about this trick, but you do not know this trick. The C++ incarnation is mildly funky but flexible and tidly solves a host of messy structural issues. And it's easy to read if you actually think that way, which IMHO, any practicing programmer should be able to do.
When all you have is a hammer, every problem starts to look like a thumb.
I've interviewed lots of guys with 20+ years experience who have never really worked on anything very challenging and are basically at the same skill level as someone with 3-5 years of experience. Given a choice between a guy with 3 years experience and a guy with 20 years experience who are both at the same skill level, I'll prefer the guy with 3 years experience. Why? Because if after 20 years your skill level is the same as a guy with 3 years experience, your skill level isn't likely to improve. The guy with less experience is more likely to continue to grow and be more valuable in a few years.
It's worse than that. People who look like sheep staring into oncoming traffic when manual diverges from reality are just missing their calling. They should be studying for a divinity degree if reality is so foreign to them. Yeah, real world works a tad differently from what's written down. Except maybe if you study hard sciences like physics, but even then it takes a few decades of experience to get a feel for what's missing between the lines.
A successful API design takes a mixture of software design and pedagogy.
Do they include noticing that the same topics come up over and over again on Slashdot?
And there I was wondering if I should experiment with the open ada compiler I found in my Linux repository.
Guess it wouldn't boost my chances for getting employed as an ageing developer tho.
If I had a DeLorean... I would probably only drive it from time to time.
70's: PL/1, Assembler, Fortran
80's: C, Lisp, more Fortran, Basic
90's: More C, TCL, VB; VBA
00's: More TCL, more VB/VBA, HTML, JavaScript, SQL
10's: PHP, Java, C#, more SQL, less VB (:-)
And I'm still this side of 50. What do you have that I can't work with?
It started as a Chess program, then became 2415 times smarter since then, controlled a network system, then was going to control the humans.
funny, now i realize that the MCP was a sort of DRM, defeated by hackers to make the system free!
Okay, have to watch Tron again now...
Be seeing you...
This isn't too surprising. As a 40 yr old engineer, I am halfway in between the two worlds. For the record, I am in management, but still can hold my own against a lot of engineers.
(Good) older engineers usually can bring either broad system experience where they see patterns and nothing phases them. The other type of (good) older engineers have a depth of vertical experience in a very tight sub-domain. iOS, Android and Windows Phone are Yet-Another-Operating-System (YAOS), same general patterns, same problems. System thinkers (the first type of "good engineer") revel in this type of YAOS.
Some of the newer areas like .com world is a bit different in that the domain is extremely wide (that reduces the pool of those that meet the "good" bar above) to know everything, you need to know databases, HTML, javascript, networking, etc... This younger engineers have the benefit of a similar depth of expertise as the old ones, but the breadth of the area is too wide to help the system thinkers show their strength. Plus the younger engineers don't have the commitments, don't always have the work/life balance, and have more stamina.
can younger developers learn new tricks? most of the ones i see are trying to imitate techniques from 90's. or worse, from the 70's. they will argue till they are blue in the face, that those were the best ones. largely because they don't even know how scalability problems arise and how they have long been addressed. the reason they are biased against older developers is that the younger crowd doesn't know how to write anything but a throw-away proof-of-concept. they think there is no need for design. and for every 2 hours they save on design they waste 2 weeks of someone's effort to make backwards prototypes work. the truth is that writing software is akin to writing prose. there are those who'll never write anything but 3rd page of a local paper and those who'll write timeless novels. most new developer are just like new writers -- thinking they deserve a job at ny times while completely unable to produce something of lasting value.
Any guest worker system is indistinguishable from indentured servitude.
If you are over 30 and a programmer, your walker will be arriving shortly. Security will be on hand to escort you out.
Thankfully, not all companies are that shortsighted. :) I'm past your limit by 20 years now, and yet I'm still elbows deep in code and relatively young compared to many of my cow orkers, though as of last year it's more shell, PHP, Perl, and C++ bits than the Fortran 77 I was writing back when I started my career.
My most recent partner in crime (manager, teammate, etc.) just retired in January of this year. He had 20 years of seniority on me, literally, and he was still very very good at what he did.
Don't underestimate the combination of a good mind, good training, and a few solid decades of hard-earned OJT. Sometimes younger programmers are better, and that's good, but having an old fart or three around to mentor (and help by spotting and correcting blatant mistakes) is one of the fastest ways to learn. I had several mentors coming out of college, and i'm thankful for all of them.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
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.
I'm a hiring manager for a software development team; one of the front-runner candidates we have right now is a woman who did software development for donkey's years, then went into architecture for 15 years, then retired, then realized she really wanted to get back into coding.
She was rusty in our first round interviews when it came to actual coding, sure. We expected that. But we also expected her to think about design and architecture the right way, and to ask the questions we would want a great candidate to ask -- and she did all of that.
So we asked her to resolve one of the issues logged against a product we open-sourced; we get to see how quickly she can spin up knowledge of github and our code base, she gets to do some code she'll be able to point to as part of her portfolio (since it's an open-source product, her code will be open-source and visibly hers as well). Everyone wins.
Vicente del Bosque, the manager of the Spanish national football team, is 62:
http://en.wikipedia.org/wiki/Vicente_del_Bosque
Unfortunately, the ageism http://en.wikipedia.org/wiki/Ageism is very widespread nowadays. Only too often green inexperienced employees get the positions of authority without an experience, without a clue. It is one of the reasons of the current economy crisis.
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.
If you are over 30 and a programmer, your walker will be arriving shortly. Security will be on hand to escort you out.
You're a fucking moron if you believe this. 95% percent of candidates I interview under the age of 30, I kick to the curb, because they have zero computer science knowledge or sense. Little to no knowledge of data structures. Certainly no knowledge of how data structures work, or algorithmic complexity.
At a risk of generalizing here, the problem is that "computer science" is being taught by those that can't, rather than those that do. CS isn't being taught be experts, because it is far more lucrative to practice than to teach.
I'm 31. Last year, I grossed over $220k. I'm good, but I'm by far an expert. How many of you young wipper snappers thinking AJAX is the only way to program can say the same, unless you own the company?
There are several ways to being a prolific and profitable developer
Increase your toolset. Just knowing a single toolset, even if you're an expert, doesn't make you more employable. Knowing a single toolset, and only a single toolset, makes you infinitely replaceable and your cost will never justify itself to the company's bottom line.
I personally understand currently 5 different assembly sets. Why? Because in some cases, I've actually written the assembly. In others, I've had to debug into the assembly, at which point, I needed to understand the architecture. And if you think because you work in a higher level language that this will never affect you, I call bullshit: at some point, at some time, it will affect you, or bite you in the ass, but you probably won't even notice it."
I can read C, C++, C#, Java, Python, Perl, various shells. I would only claim to be able to write C, C++, C#, Python. I can work under various architectures/OSs such as x86, x86_64, MIPS, z80, 68k, zOS, Windows, Linux.
At the end of the day, a quality developer will choose the right tool for the right job out of the developer's toolset. And, at times, recognize he/she doesn't have the right tool, and learn a new one.
Case in point for me, today: I had a need to programmatically identify functions of a certain name that were, or were not, calling another function of a different name. I spent an hour or so looking online at various tools such as gccxml and synposis, and determined, they either would not work for me, or would take too much effort to implement. Instead, I was able to implement a sufficient solution just using regexes, and minimal scanning. Right tool for the right job.
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.
I thought the 'bias' was because they demand real wages and are harder to treat like slaves.
No sig today...
When I was an intern (19-22yrs old), I worked for a group that was predominantly in their mid 50s. I learned a lot from them, I also taught them a lot. I learned from their experience, this is how things work, etc...what I taught them was what I learned just from trying, without their preconceived notions. Sometimes their way was better, sometimes my way was better; but we always got the same result. The key here was: profile. Old school & new school. They both work, and give the same result, which is better? Prove it.
note that being an older programmer does not obviate the possibility of having a young lover
I don't know where that came from, but I can't say I disagree, not at all :)
A successful API design takes a mixture of software design and pedagogy.
CaN brain-dead numbnuts quit quoting "Betteridge's law of headlines"?
Well by applying Betteridge's law the answer is obviously .... Oh wait!
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.
This is the comment of the day. Thank you!
A successful API design takes a mixture of software design and pedagogy.
They're old farts, only know Cobol and Ada. It's impossible.
Bah .. steer away from those new-fangled languages and stick with good old autocode
The main reason older people don't like pulling 80 hour weeks (routinely) is that it is counter-productive.
Interestingly, I suspect this comment may have more insight than it first seems I wonder if younger programmers see "I know cobol and ada [as well as modern stuff]" as "I only know cobol and ada". That is, the perception that they're not keeping up with modern techs is exactly because they know more techs, and are able to discuss alternative ways of doing things, rather than just doing stuff the [insert cool modern tech] way straight off the bat.
Actually, he's in the right. You should go back to school and ask for your money back. Doing something undocumented is a really good way to be doing something broken in 6 months when stuff gets updated, and now behaves in a different (also undocumented) way. Things not doing what the documentation says they should just increases the risk that this is going to happen – it suggests that the guys writing the API have no clue about maintaining compatibility between releases anyway
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.
Uh actually - I just turned 45. I was coding mostly C and some C++ when I was 30 and Java was just starting to get noticed.
Anyway, at 45 I probably get contacted by anywhere from 1 to 5 recruiters a week. I also haven't gone more than 2-3 weeks without work in the last 20 years without either a job offer or the next job lined up. In fact, at this point, I have to avoid recruiters just to get a little time off between contracts or jobs.
I don't consider myself the best or a genius. I'm probably in the top 20% of coders - but definitely not the top 5%. Yet I find myself arguing the same arguments and solving many of the same issues from company to company because so many folks fail to see the bigger picture. Yes, I have been let go a few times in my career, but its mostly because I wouldn't convert from contractor to a perm position or because of political reasons. I don't think I've ever been let go in a true lay-off, and most of the time I choose when I leave my job and move onto the next one.
As for the walker - thankfully not yet. I still manage to lift weights and hike/run/bike in my spare time..
I guess 45 is the new 29. :)
As an older guy - I have no problem helping younger guys out. I have had a lot of mentors over the years and I still learn from those more experienced then I am. I just get a little torqued up when someone young comes along and thinks they know all the answers and starts trying to "boss" everyone around. Usually these guys are the first ones laid off or forced out, as they are not team players.
Did TFA intentionally use a 10 point font that's too small for older people to read on this article? Maybe I'm getting too old, but I was cont-+'ing that a half dozen times so I wouldn't have to use a magnifying glass.
Actually, I'm a lot older than 30. That was a jab at places that brag about the youth of their workforce.
When I started in the field, your language choices were mostly assembler, COBOL or FORTRAN. Except that I did OS programming, which meant that your choices were assembler, assembler, and assembler.
I've picked up a few more languages - and a few more assemblers - since then. Also a number of programming disciplines, UI frameworks, done some bare-metal real-time process control apps, several OS's, etc. etc. etc. Usually by the time a technology has gone mainstream I've been working on the next one.
And if I catch you walking on my lawn, I'll set the dogs on you!
After developing C++ for so long - I indeed feel like an ape, I'll give you that. For the past few years I have been confined to C and assembly (various embedded projects) and I tell you it has been glorious.
I am very small, utmostly microscopic.
>> solves a host of messy structural issues.
They eliminate some code I"ll give you that. However you have no clue as to what the compiler is actually doing... and for that I click "Do Not Like." (Actually now I am going to disassemble some code to take a gander for myself.)
I am very small, utmostly microscopic.
How can we have an intelligent discussion about the Cost-Effectiveness of older programmers vs. younger programmers without a method to measure programmer productivity? The only thing measurable is the "Cost." The "Effectiveness" part is left out completely. When you come up with a generally accepted method for measuring programmer Effectiveness, please let us know. Until then, I predict, anti-old-programmer bias in hiring and layoffs will continue in most organizations.
How does an individual programmer deal with this bias in her own career plan?
Option 1: Burrow deep into a niche technology upon which one or more corporations depend for tens of millions (or more) dollars in profit. Ideally this niche technology will be as attractive to current CSci students as learning COBOL is today. Show up for work everyday. You'll have employment opportunities well into your 70's.
Option 2: Start a small business. Software businesses have notoriously low start-up capital costs. If you can identify an unmet or under-served software need of a number of small or mid-sized businesses and work with potential customers to come up good solution, you can create a business that will feed you and your family until you no longer want to work.
Option 3: Bag groceries, deliver pizzas, work seasonally at the post office or in retail or try real estate or insurance sales or used car sales when you're 55 trying to survive to 65 and Social Security/Medicare.
I've seen a large number of techies (not just programmers, but Engineers as well) choosing Option 3 by default because they didn't want to stare the grim reality in the face.
An old myth was that COBOL killed developers brains - somehow programming a structured language killed people's ability to learn anything else. I've known COBOL developers who actually DID have difficulty learning anything else in older years. But that may have more related to corporate conformity and how they were trained. Back in the 60s & 70s IBM men only wore a dark suit, white shirt, and red tie. IBM wasn't exactly recruiting Berkeley hippie types. And they were forced into training courses to learn COBOL at work, like it or not, sometimes for months at a time. So the non-conformist, innovative self-starter who today learns say Linux, Perl or Ruby on their own was not exactly prized decades ago.
The real question is can the new young guys learn any of the old tricks ...
The old guys know all these, and mostly keep up with the new stuff (where they can see a future for it) it's the new guys that need to catch up ...
Puteulanus fenestra mortis
Back then, developers with a real background in computing were rare and demand was high. As a result, companies hired many people with skills only vaguely related to computers. If such people just did their jobs without acquiring the necessary background in the process, the fact that they have difficulties now is understandable.
OTOH, older developers with an extensive background will have no problem adapting to newer technologies because in the end, the techniques don't change that much.
All the good tricks were worked out in the 70s when people wrote real code in real langauges (C, Forth, Smalltalk, Lisp) for real machines and things actually... get this... actually... (shudders trying to get the blasphemous word out...) WORKED! Then came the dark times, the second order postincrement operator and its subsequent application to that most beautiful of low level langauges... then they ripped the heart out of Smalltalk and stuffed it to another offshoot of that beautiful low level language... lists became list<int>'s and even the free variables were frogmarched into class { } and forced to do all their best work in { private: } only showing in { public: } what was acceptable to the evil overlords to be shown. Oh the horror!
Things were good in the old days. Then there were the brief happy days of the eight-bitters. The Amstrad 6128 was my idol then. It booted in just under two seconds, you could program just by typing a number followed by a space and then your code; you could run by typing run, without... get this... without even compiling, and things just worked... or else just crashed the computer, but there was always ctrl shift escape and, if that didn't work you could flick the off switch without corrupting your data, and did I mention it booted in under two seconds! Oh how far we have fallen in our search for crystal castles with see-through walls and shiny fruit so beautiful you can't even eat it without poisoning yourself (if, that is, you can even get something 27" across down your throat).
John_Chalisque
That there is a small minority of older developers who:
1) haven't learned anything new, beyond an absolute minimum necessary to scrape by, in 20 years
2) write awful code, using C as assembly or Ruby as C, for instance
3) still think that they have such massive depth of experience that they're head & shoulders above all others
4) lord it over younger developers, flaunting their delusion of superiority
5) most unfortunate of all, often have the trust of managers that have also been around a long time.
Like the archetype of any stereotype, these outliers have disproportionate influence on other people's experience and impressions, much more so than older developers who quietly excel and keep things running smoothly.
Nobody considers doctors, lawyers, scientists, accountants, or engineers, over the hill at 40. Why is software development considered different?
Can surgeons learn new procedures after they are 40 years old? Can lawyers learn a new law?
I suspect that employers know that software developers can be productive when they are over 40 years old. But, maybe EA would have more trouble working those developers for 110 hours a week?
Although it may be hard to know an individual's history, if they have ever uttered the words, "I don't want to learn anything new," they're done. It doesn't matter if it's programming, educating or most anything else, once someone rejects further learning they are a drag on the organization they serve. Those seven words are, perhaps, the best test of burn out.
The question doesn't really make sense. When you've been around for a while, there are no new tricks, just minor variations on old tricks. Occasionally there'll be something that requires a different way of looking at the old tricks -- like functional programming or massive concurrency -- but computers haven't fundamentally changed, and aren't going to.
In most cases, the old software developers who've already seen a number of variations on the tricks are better able to pick up new tools and techniques than the younger guys, because they can say "Oh, that's like X except for Y, where it's more like Z". Details are just details, and that's what manuals are for.
Young programmers who've already had the opportunity to learn three or four programming languages should be able to extrapolate from their experience with the last language or two, by which point learning the language is just a matter of remembering a few details of syntax and exploring the libraries. When you've been writing code for 20+ years nearly every new environment, toolset, library, etc., feels the same... just another variation with some trivial differences to be assimilated.
My older colleagues (I'm in my 40s but some of the guys I work with are in their 50s and 60s) confirm that adopting new technologies just gets easier and easier over time.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Older engineers, if anything simply want to get real work done.
New technology, for it's own sake, falls into the category of "bullshit."
For example, neither Silverlight nor WPF ever seemed to have added much but stylistic nonsense. You could have extended Winforms, added some properties that were useful to web presentation and gotten a better, more usable result. In contrast, HTML5 and Javascript actually seem useful as far as getting a product or service to customer in a timeframe that matters.
So the former technologies exasperate. The latter do not.
I also think that at you've seen the same concepts renamed and repackaged over and over again, you just get jaded. It's mainframes and dumb terminals! It's servers and internet connected machines! It's the cloud! Yippee, everything old is new again.
FYI, at age 55, I am responsible for the care and feeding of a herd of VMWare 5.1 servers. Virtualization is probably one of the most useful technologies to happen along in a while, and thus, I'm all over it and learning to script in Powershell, despite it's god-awful syntactic structure.
Please do not read this sig. Thank you.
Structure returns used to suck in GCC code generator wise, now they are fine. The same will be true of lambdas. They offer optimization opportunities if anything.
When all you have is a hammer, every problem starts to look like a thumb.
Sugar. The term in Syntactic Sugar. Not candy.
And while you can certainly implement almost any language construct in C, like object oriented class inheritance, it's not always a good idea.
When I started in the field, your language choices were mostly assembler, COBOL or FORTRAN.
Oh come on! I bet you had those new kids on the block RPG and PL\I, too!
But I might be showing my youthfulness. And I'll get off your lawn before you sic your dogs on me.
That is all.
I have been programming since 1975 beginning with IBM 360 Assembly Language, then FORTRAN, then Pascal, then C, followed by C++ and Java and lately been getting into Scala. The craftsmanship improves over time. Us "old guys" may take a little longer to put up code but we make a heck of lot fewer mistakes than the newbies. And yet, there is an unshakable sense that there is an age bias in this business. /s/ Cary Scofield
http://www.linkedin.com/in/caryscofield
It won't be the case that people's reps will go down as they get older. It's hard to lose significant rep unless you screw up seriously.
However, the site is five years old. In terms of the human lifespan, that's not that long. While it won't work for differentiating 28-year-olds and 30-year-olds, it works fine for differentiating people in their twenties vs. people in their fifties.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
... it's easy to read if you actually think that way, which IMHO, any practicing programmer should be able to do.
Having used lambda functions since I learned Lisp in the 1970's and having used C++ since the cfront 1.0 days, I can honestly say that "easy to read" is not an attribute that most templated C++ code has, lambda constructs notwithstanding. In fact, many programmers hide templated types behind typedefs for this reason. It's not so much that one could conceive of such a thing being possible, it's just that it's appearance in the wild would be of the same order of likelihood as looking out your window and seeing a black swan.
Besides, even if you do write "pretty" C++ lambdas, the screwing up of syntactic closures and inability to return lambdas involving the same without remembering highly idiosyncratic rules about variable capture lifespan or (even worse) copying semantics (and, copying variables rather than sharing references is almost always a mistake, language design-wise) makes anything more than simple examples useless.
That is all.
Templates and lambdas are two completely separate things. Most of my lambda usage is without templates. And template usage is largely unreadable because of crappy STL design (eg., disallows constant expressions) rather than the template language itself.
When all you have is a hammer, every problem starts to look like a thumb.
When I started in the field, your language choices were mostly assembler, COBOL or FORTRAN.
Oh come on! I bet you had those new kids on the block RPG and PL\I, too!
But I might be showing my youthfulness. And I'll get off your lawn before you sic your dogs on me.
Actually, I wanted to learn PL/I in school. They wouldn't install it. It required 1MB of DASD space and they weren't willing to dedicate an entire Megabyte just so I could use a language that wasn't that popular around town.
Never did get an RPG program to run, though.
Given your use of the English article 'a', I will assume your sample size is too small to be of any significance.
“Common sense is not so common.” — Voltaire
The issue here is old versus new. The reality is that you will find fault in younger and older developers. Most older developers propagate the stereotype because most of them have skills that have not kept up, and therefore their productivity is not as good as it use to be. This is the majority but NOT all of them. Most younger developers have more up to date skills but although they are experts at playing all the instruments in an orchestra, they often do not know how to put it all together, to write a symphony. In other words, they may know a lot about a lot of technology, but they often do a poor job of applying that knowledge. They often misapply. They're too into cool and toys, fads, gee-wiz fun. The REALITY: You will find awesome good developers that are Old, and Young. The bad old developers were bad in their youth. The bad new developers can become great old developers in time. This issue is too divisive, and filled with a lot of mythology. I'm 53, and been developing for 34 years. I'm an old dude, but I will be the FIRST to admit that MOST of my fellow old dudes are not very good developers. Either they are lazy, complacent, don't feel well anymore, or are waiting for retirement. I am of the minority. I keep my skills as fresh as possible, and I hang with the best younger developers no problems.