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."
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.
If my grandma can learn how to use an iPad at the age of 85, never having used a computer in all her life, then a 50 year old developer should have no problem picking up 'new tricks.'
"First they came for the slanderers and i said nothing."
How about "I know how to write quality code, but I'm no longer interested in spending the necessary cycles to learn every new faddish tech. that comes down the pipe"?
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. :)
It's one of the benefits of experience that you know what to skip... although it's not always the same things for everybody.
I think a better question would be, how often does something genuinely new come along?
Employers can't use a correlation even if there is one, so stop worrying about it. If learning new tricks is important for them they can ask for recent examples during the interview or test the ability directly with a question.
Don't worry. There isn't a shred of discoverable evidence that your age had any bearing on our decision to choose somebody who seemed like a better fit for the FooCorp team.
If my grandma can learn how to use an iPad at the age of 85, never having used a computer in all her life, then a 50 year old developer should have no problem picking up 'new tricks.'
If one grandma can learn an iPad, then there exists one old developer that can learn. If every grandma can learn an iPad, then all old developers can learn. Noticed the difference?
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
There is also a strong correlation between interest and hobbies - if they are doing techie things for fun, they will usually be in the wizard category.
I can't really disagree here, but I wouldn't say that the correlation be restricted to what is considered a 'tech hobby'.
I have known a number of men in their upper years that I would classify in the 'wizard' category, yet their hobbies included things like fly fishing, baseball statistics, flying small planes, etc. I would really consider any of these a 'tech hobby', but I would consider them hobbies that require a great deal of technical aptitude to also be a wizard in.
Keeping the mind sharp is the key. If you do that by observing local caddis fly species, tying your own imitations, nailing the presentation to the fish (including time of day, weather conditions, season, physical stealth), and ultimately landing a 22 inch trout on 7x tippet, I imagine that keeps you just as sharp in the day job than simply doing more day job like things in your free time.
Hobbies are meant to be hobbies for a reason. If you are an aspiring musician gigging at the local clubs to make your cash and you then spend your free time doing more of the same, but "just for fun", your musical career is probably not going to take you where you'd like it to.
Completely detaching from concepts related to your occupation/career during your "me time" is absolutely essential to having a long enough career to ever become one of those "wizards". If you're a programmer, and you spend your free time programming for fun, you'll certainly become a solid developer, but there are very few people who love code enough to be able to sustain that for 20 or more years.
TL;DR - going fishing is better than having a 'tech hobby'.
Someone flopped a steamer in the gene pool.
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
My experience in hiring programmers of all ages is that older programmers are more reliable and less management overhead. They tend to be less prone to take risk (experience does that to you :) Generally more productive but not necessarily pushing the envelope. That is, of course, a gross generalization. There are some old dudes who rock.
Young (or rather, inexperienced) programmers tend to offset any productivity with management headaches, bad risks, missed deadlines, etc. But they offset that with a (charmingly) naive push into the novel (mostly due to ignorance). Again, a gross generalization. There are some younger dudes who "get it".
Since programming is still not proper engineering but more of a craftsmanship, a combination of both older and younger programmers makes an excellent combination. Younger pushing the older by questioning assumptions. Older training the younger, by bringing perspective and discipline.
amen. The thing with old guys is that we've seen the fads come and go - did you jump to learn Silverlight, Linq2SQL, etc? Yes, well, fool you. The old dogs take their time to see if a tech is actually any good and worthwhile before going crazy for it - unlike a lot of younger guys who seem to think that if they haven't completed a project they can move to a different tech and then fail to complete that too, but without anyone noticing!
Its the same with a lot of stuff- .net moves so quickly that no-one really became a true expert in it, as soon as you learned one tech, it was scrapped and a different one with the same name and different version came along - ho hum. The old guys remember when you made things properly first time (or, if a MS dev, waited for version 3 before taking notice of it)
It simply wasn't possible to be a good programmer (by today's standards) in the 1970's. You could be a good programmer for the time.
Tex was written in 1978. There aren't many people today who write code of that quality today.
Good programmers write good code in any language; crappy programmers write crappy code even if they unit test every line of code in an OOP system using MVC (although the code will be less crappy than if they didn't use those).
"First they came for the slanderers and i said nothing."
I'm not so sure about the contacts. I have recruiters ask if I know people who are looking for jobs, and to be honest, I never do. The ones I know out of work I also know aren't a fit (hardware guy for a software job, etc). Plus lets face it, I'm a techie, not a social butterfly, I don't keep up the contacts with all my past coworkers.
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.
Once I was searching for a new job and an HR type rejected me because my CV did not show Visual Basic.
This really irks me these days. Most job offers are buzzword bingo with a long list of "absolutely required" niche technology du jour stuff, none of which are particularly hard to pick up if you're a half-decent developer, but you will NOT get past the HR drones because you don't tick the boxes.
Found out later that class was made optional for later graduates. As the curriculum standards are lowered so will be the graduates ability to handle stress or workload
I'm 24, and I can verify this. Undergraduate level Comp Sci at a typical school is a joke these days. It is typically a thinly disguised Java programmer factory, since not enough schools make a distinction between computer science and software engineering. It's always bothered me that I was expected to just accept all of the low level hardware and software workings of a computer as magic, that it was supposedly a good thing that I didn't have to worry about them. I've invested a pretty significant amount of my free time studying those topics, and it's embarrassing how few of my developer peers (age-wise) have enough knowledge to have even a basic conversation about them.
It's great that I can use a language like Python to fire out a decent application rather quickly. But what happens when there's something you can't do with Python, or you need faster performance than Python can give you for a certain module? There's no excuse for a professional software developer to not be able to bust out a native implementation and give it a wrapper in a "nice" language.
Apparently wizard is not a legitimate career path, so I chose programmer instead.