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
how could your reputation start from high and go low as you get older on stackoverflow?
I would argue that most reputations on stackoverflow get higher as time goes by, since once your reputation goes bad, you're unable to do most things on the site so those accounts get abandoned. of course very few people would have the persistence to consistently give bad answers on stackoverflow in the first place. a right answer gets upvoted for years, while a bad bad answer gets downvoted just few times as well.
now, has he done the same thing with slashdot karma??
the underlying premise that coders would get worse as they get older is of course bullshit. with some people you might notice it better once they get older though, but those are very unlikely to be answering anything on stackoverflow.
That is all.
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...
old people have higher Health Care and don't like pulling 80+ weeks.
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.
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.
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?
Maybe your mom doesn't know as much tech as your younger sister. But since a programmers job is to keep up with technology, they'll do it. And there is nothing that prevents them from being able to.
Face it, a lot of companies just don't want to pay the salaries. A lot of young programmers are intimidated by the experience and abilities of an older programmer.
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.
Give an example of a "trick". What are you talking about? Why do obvious non programmers write stupid posts?
Its common knowledge that the most experienced you are, the more capable you are.
THAT TAKES TIME
Work that out you genius.
Don't forget to add things like LISP, snobol, prolog, Pascal, Modula-2, SML, APL etc. :-)
Does he/she know something you don't but you are too young and naive to realize yet?
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.
As a younger guy, I'd have no shame coming to you.
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
Does he want to maintain gains in worth by upgrading skills?
Like you I've coded in a lot of different languages over my career. The ability to learn and use new languages gives us a natural "agile" skill set that only comes with experience. Sometimes you don't have enough time or resources and you're still expected to get it done right and on time. Not knocking the younger crowd as they'll get there too.
Trolling question is trolling.
It is rare to be an all-in developer for over a decade and to not be self-employed and/or retired. We all have the superpower to create products that can be magically replicated an infinite number of times. If you know how to check if your chip is flashing, maybe you'd better start your own business.
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.
Most of the kids fresh out of school know one or two languages and they think they're the end all. I've met people who don't know what design patterns are. Seriously, I think there's like one graduate from each university that knows what they are doing. The rest cheated off that guy.
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
It has been for a long time, which is a riot, because I'm seeing a lot of folks that used to sneer at old farts losing hair, buying Boxters and hanging out at raves.
[url=http://professionalsuperhero.com/]I love the ad at the end[/url].
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
This question usually becomes whether you can learn new languages as you get older - but it's missing the experience that older programmers have in already solving the problem. It's more useful understanding why a user wants to do something and being able to offer alternatives than rushing off and writing the wrong program.
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
Am I too old to stay up all night with a 20 something lover?
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.
The junior came up with the right questions to the problem: lack or incomplete documentation.
If clowns around got away with that *everyone* should be fired for negligence and incompetence.
FYI that's just how the pros work.
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.
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 would advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date. - David Parnas
You're old when it takes all night to do what you used to do all night.
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.
And an entire raft of assembly languages.
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.
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.
I'm old enough to remember how badly Ada sucked.
-jcr
How often do I come by code that is still written like it was 1979.
Today we live in a multi-threaded, 64-bit, TB hard drives and double-digit GB's of ram systems. But the average program is written for 32-bit single-core systems with no care taken to the disk i/o speed (remember when we all moved from XT's to 386's and software stopped working because the systems were to fast?) This is just redux, here's a quick list of software that is guilty:
1. Java (requires Java software to be written against the 64bit JRE and most "addon"s are not 64bit, trying to use most java software will execute only on the 32bit JRE)
2. Flash (player and authoring tools, single threaded)
3. Chrome (single threaded, no 64-bit version)
4. Firefox (of which they've being going backwards, first eliminating multithreading, next trying to stop doing 64-bit versions)
Look at all the poor advice here:
http://stackoverflow.com/questions/1222574/c-main-loop-without-100-cpu
If we can't teach new programmers to use 64-bit programming techniques and multi-cores, then we've reached the plateau of what can be done about 7 years ago. CPU's aren't getting any faster, and newer software (like Final Fantasy XIV ) just is slower their their previous installments in the series. Software like MS Office becomes slower as more and more software tries to do things under the assumptions made 5 years ago about improving performance.
Like the worst offenders of this are MMORPG games that were written at the end of the P4 era when we all stepped back 5 years and cut all the core speeds in half. A game written in 2003-2004 performs WORSE on 1-5 year old system than it does on a 3Ghz P4. Even with much newer graphics... because a lot of programming is being done inside a single thread inside the game engine, not being pushed to the GPU, and not being pushed to other cores.
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.
I am. I like learning new things. Most of the software developers I have met do not however.
Unlike many youngsters I am more critical of trying new things just to be trying new things. I also don't think everything old is crap and has to be rewritten.
If learning new things is more important to you than baseball, movies, beer, etc. then you have nothing to worry about. If your focus is elsewhere then you better hope you didn't blow all your salary on beer when you were young.
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.
Articles like this are so stupid.
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.
File "Betteridge's law of headlines" along with "All Your Base" jokes, Star Trek SNG Picard jokes, "But does it blend?" jokes ...
And everything else long past its expiration date.
Nobody has posted anything about the complete lack of understanding that "law" is curtailing innovation. Age is not the factor here. Once you work for a big corporation you will understand why it is not worth the time and effort to continue to innovate. Why would I/you develop anything worthwhile if all I'm going to get is a pat on the back when working for a company. Everything you do is owned by the company by contract. Sure some companies compensate well, but they are few and far between. Work enough to get paid, to pay the bills, never give it away for free. Young people haven't had enough familiarization with the law to understand what they are truly worth. Actually maybe they do, and that is why we see increased usage of H1B visas to "fill the gap"; to get rid of people that understand law. To replace people with clueless programmobots.
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?
Yale won a case against him on a patent and the judge ruled - "Dr. Fenn only obtained the patent through fraud, civil theft, and breach of fiduciary duty."
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.
No, the "experience" you are talking about is relevant to the specific project described. Most likely it was the programmer who failed to maintain up-to-date documentation. His "experience" allowed him to provide the answers because he is the one that made the mess.
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.
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...
watched an old fart open an AVI today
squint, search for file, squint, see what ext it was, squint right click, squint choose open with, squint, read list of 50 fucking players including real, squint, choose VLC, squint play .. and the damn thing still didn't run
double clicking the fucker started up wmp and it played fine
dont
have
time
for
stupid
old
fucks
and this is our senior software engineer, makes a mountain out of every molehill, cause thats how he was trained in the 70's when computers were just on the edge of reliable
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.
As if an AVI would open in WMP but not in VLC. Go back to playing with your etch-a-sketch.
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!
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.
You need to be honest about that second question: Is he/she naive enough for me to exploit for twice the hours I'm paying them for, and stupid enough to agree with my false proposition that more hours means more work at the same quality.
That seems to be the real problem the tech industry has with older workers.
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!
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.
All of those 'scripting' languages were created for
1: Provide live code ( recall that java script was firstly named 'LiveScript' I wonder WHY java is named Java when it is more like 'Live-c++' )
2: Provide augmented features without having to re-building the base code - and now EVERY Linux installation programs are 'LiveScript' -alike
3: C/C++: Becomes way too hard and complicated to maintain software based on c/c++ nowadays.
4: New young programmers call themself 'programmers' without having to touch anythings but Java and above....
5: C/C++ now is far-away behind the scenes, if not for game coding, Qt,KDE,GTK. ( Microsoft: For Microsoft, C/C++ is "Ancient Aliens" already )
6: Now, C / C++ (and PASCAL as of Win32 uses the PASCAL call-stack) is called 'EVIL' while it is still the BASE( one level above pure ASM) of everything...
I am Acient Aliens :-)
How "old" are we talking?
I learnt programming using ADA on paper tape, then BASIC and Mnemonic Assembler on green screens with 8inch floppy discs.
I currently use C#, VB.net with HTML5 & SQL - mostly web-enabled data consumption applications.
I've never seen any evidence that age affects ability, or ability to learn. You can't teach an unwilling dog new tricks, but anyone who wants to, can learn something new.
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?
Also, to more quickly expedite this process, I prefer your story submissions in the form of "Ask Slashdot: Am I Too Old To <X>?"
Am I too old to get a date with that 20-something YO hottie in accounting? My wife says yes. What does Slashdot say?
I have never worked with a 25 year old Oracle DBA. I am almost 39 and have been in the business for 14 years. I started as a developer and moved over to DBAs. Oracle DBAs tend to make alot more money than developers (in part because we tend to be on call), so you generally don't hire kids out of college. Interested developers (many of which are interested in the larger pay check) move over after several years of experience.
Part of the reason for this is if we make 1 mistake in production, it can cost alot of people their jobs (yes I have seen DBAs fired for 1 mistake before). So you want people with 10+ years experience in the software/DBA world. I find that the more experience I get the more in demand I am. I also find that I am also better at getting the young kids to do what I tell them to as I get older. Part of is from experience of seeing these kids make the same mistakes as the other kids I worked with. So I know how to catch these mistakes early and I know how to explain what they should do differently in programmer speak. I tend to like to explain DB issues using Pseudo C code (this can be an issue with java guys who don't know C or understand how to manage pointers).
I tend to job hop a lot. I have not stayed in one place more than 2 years in my life. I have never had trouble finding another position. That being said, the vast majority of my jobs are found from just sending my email out or some recruiter contacting me because they pulled me off a website. I have friends all over the place. It doesn't mean they are hiring, doesn't mean they are paying what I am looking for, doesn't mean its a job I want, doesn't mean its the nice short commute I like.
Some young guy called someone my age a 'turd' for sending resumes out online. Yet this turd probably commands 2x the money you do. My salary continues to go up as I get older. That being said, I don't get more money because I am older. I get more money because the added experience (job hopping adds to experience because you see a wider variety of issues) and my productivity improves. I also find it easier to solve problems. When I was younger I was figuring out problems as I went along. Now its more common for me to see how a new problem is similiar to older ones and I am able to draw on those experiences to come up with better solutions. In the past I would have to refactor more. Now I can use the experience I gained refactoring to do something better the first time.
This type of thing only comes with experience.
There is a downside to being older and higher paid. When the company is cutting back, your name tends to be at the top of the list. Companies tend to cut the highest paid people first. This is one of the reasons I don't bother sticking around long enough to be considered the 'old guard'. I'd rather just roll. And if your wondering how I do it... Just tell them 'the company is moving jobs to India'. Or if you do work with the government 'my company lost the contract. Works every time.
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.
Maybe you meant "old".
In my (admittedly anecdotal) experience, I've generally found that older developers are strong believers in the idea of "locking things down" as much as possible, whereas the younger developers tend to not see as much value in doing that.
One example: The older developers in our department are big advocates of strongly-typed languages (C++, Java) and are skeptical of developing large amounts of code in weakly-typed languages (Python, JavaScript, bash). The younger developers don't seem to have this attitude. This fits the pattern -- the older guys favor the approach that "locks things down" more, to prevent errors as early as possible.
Another example: the older developers are a big fan of SQL's ability to enforce referential consistency in the data. It's only the younger developers who are interested in pursuing NoSQL solutions, in which enforcement of consistency is moved to the application. Again, it's the older guys who are more oriented toward "locking things down" at as low of a level as possible.
Another example: the older developers tend to favor a very minimal and restricted UI in our products -- they are always looking for ways to NOT give the user a choice -- they argue that the fewer things we allow the user to do, the less can go wrong. The younger developers tend give the user a lot of choices and features in their UI. Again, it's the older guys who favor "locking things down".
The young guys tend to see the old guys as "curmudgeonly", "scared of new ideas", and unwilling to loosen up and embrace new technology. The old guys tend to see the young guys as not yet having learned the lesson that 95% of software engineering is dealing with bugs, and so you get the biggest payoff by aggressively locking down everything you can get your hands on.
Has anyone else seen this pattern?
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
do yourself a favor, go back and reread "How moved my cheese?"
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.
THAT's your idea of incompetence? GUESSING what tool is needed to run what ever codec is hidden in that AVI file? You do realize AVI is just a container format, right? Kids...
The whole experience of learning new languages came to a stop when I found I couldn't learn Hindi.
1000%
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
About Europeans being more productive. This is NOT true. The most productive workers in the world are Americans. Not the Japanese. Not the Chineses. And ESPECIALLY not the Europeans.
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.