Slashdot Mirror
What's the Shelf Life of a Programmer?
Esther Schindler writes "Why is it that young developers imagine that older programmers can't program in a modern environment? Too many of us of a 'certain age' are facing an IT work environment that is hostile to older workers. Lately, Steven Vaughan-Nichols has been been noticing that the old meme about how grandpa can't understand iPhones, Linux, or the cloud is showing up more often even as it's becoming increasingly irrelevant. The truth is: Many older developers are every bit as good as young programmers, and he cites plenty of example of still-relevant geeks to prove it. And he writes, 'Sadly, while that should have put an end to the idea that long hours are a fact of IT life, this remnant of our factory-line past lingers both in high tech and in other industries. But what really matters is who's productive and who's not.'"
Why is it that young developers imagine that older programmers can't program in a modern environment?
Although I'm fighting anecdote with anecdote, I've never seen this happen. The only people I and my young coworkers assume can't program in a modern environment are people who have shown that they're unable to program at all.
I'm 50, and with 30 years' experience, growing up with the Software industry, I do fine.
I learn better today, than I did at 25.
Back then, I just knew how to do stuff.
Now, I also know WHY it works. Right down to the bone.
My years of experience and nonstop training (self-training, when my company didn't want to foot the bill) has paid off in a big way.
However, I have absolutely no illusions at all that I'd have much of a chance in the job market.
In the day of the "brogrammer," there's no room for gray hair. I'd have to start my own company (something that I'm quite prepared to do).
I get paid to manage younger programmers. I code for fun.
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
hostile to older workers.
Hostile to expensive workers. Combine with the notorious inability to evaluate programmer productivity, and ...
how grandpa can't understand iPhones, Linux, or the cloud
I'm technically old enough to be a grandpa, in fact in the inner city I'd almost certainly be one by now (its a cultural thing, "my people" tend to get married a bit older, vs some cultures its all about the teenage/highschool pregnancy, etc) The funny part is despite my apparently grandfatherly age I've been there the whole time for all three examples, and that's not even all that unusual. Great grandma might have some issues, but not my generation.
Now pick a fad that I am the wrong age for social reasons, that I intentionally skipped because I thought it was dumb, like SMS text messaging, or twitter, or myspace, then you've possibly got a point...
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I'm of the younger generation, but I've worked with all the age groups at some point or other on multiple occasions, and what I've found is... older devs tend to be more encompassing, think their approaches through, and have the jist of how to tackle a wider range of techniques / fixes (experience). Younger devs tend to be faster coders, better out-of-the-box thinkers, and more motivated to do the work (typically, comes from having something to prove), as well as try various approaches at solving a problem. There are high & low programmers in all age groups, I've met people 40+ who rattle code off methodically without external references, and those that can't rewrite a render method. A lot of "newer" code is "older" code optimized, all AJAX is is javascript more or less, insanely complicated javascript at that. A lot of big wig types find it easier to deal with somebody that is more their peer also. Another thing that comes to mind is "culture", bringing a 20-something year old into a team of 50 year olds has some serious cons to consider. There's a ton more factors, but there's a reason age isn't listed on resumes, and that's because it's the shoe that fits that you'll wear.
I think this is perhaps the biggest thing, and might explain what made my dad finally burn out (at 50).
People keep re-inventing the wheel, with the same shortcomings as the previous iterations, only with 10x the code.
Back in the day it used to be possible to actually know the code, both the code of your development team as well as the code of the tools you used to produce a product.
But today? The sheer breadth of a codebase combined with it's usually short life on-market (See every version of mono producted, and every version of java past... 1.4?) has caused it to reach a point where it's senseless to put in the time to learn the cornercases and undocumented features of a library, tool, or codebase, and rather to just work around the current issue and ignore the rest because 'it'll either get fixed when it's a glaring problem, or it'll get fixed in the next version of tool X I was using.' Only half the time when one of the bugs gets fixed a new one pops up in some existing code, or a workaround for a no-solved bug. And then the mess starts all over again. Only in 2 years time it won't matter because either the dev staff has been laid off, or you're being told to do it in .)
While it's not to say none of this happened in the past (Because it assuredly did!), the amount of different code any one person was likely to run into in a few years of development was generally less than it might be today, although the odds of any one person being overspecialized or underspecialized in a group of languages is probably about the same.
People need to look into spending less time reinventing the hammer, and more time on consolidating the numerous nails that have been produced as a result of hammer-mania. Perhaps then people can get back to focusing on good development practices and educating themselves on new platforms and tools.
Ah, There is the difference, just as you might say that a novelist is a craftsman rather than an artist. There is a level of understanding and experience that transforms the craft to an art. If you only think of it as a craft then for you it is a craft and will always be a craft, but as the best engineering is invisible, the same is said for an artfully crafted program, with all the considerations and degrees of freedom handled, with the flow natural and maintainable. As there is an art to poetry which is just words and sentences pieced together , there is an art to programming as well. In the construction world there are carpenters, builders and architects. The architects are the artists at the top. The craft is below. It is much easier to do the art when you have wide ranging control. So not all environments allow the practice of that art. I hope at some time in the future you have that opportunity.
They allow themselves to be abused like this, so as far as the market is concerned, they want to be abused like this. As long as a significant enough fraction of developers submit and H1B visas/outsourcing can make up the difference, nothing will change.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
As an over 40 programmer with more than 20 years experience, I find your post offensive on a number of grounds.
I have a smart phone. More than one kind actually, and I've developed software for most of them over the years. Thank you.
I know from experience that solving problems requires that you understand what needs to be done first. I know that those who jump in without enough information end up working many times as hard as they need to. Sometimes you can get lucky and hack your way into a solution, but more often than not it will cost you dearly to maintain. You apparently don't get that.
I've programed in Java and I fully believe that it is a valuable tool for the problems it is suited for. I also know that many software developers leave school not knowing any other tool so Java gets used places where it doesn't belong. Good programers have developed many tools over the years and knows the limitations and proper applications for each. You are a one trick pony good for only one thing, but you THINK you know everything. Smart guys listen to the old farts and try to learn from others mistakes.
I've been doing Linux since you had to compile kernels to fit on a floppy, and back when getting X-Windows started involved actually editing text configuration files. I doubt guys like you know anything about this now that installing Linux is hitting return a few times. You can thank guys like me for making your life easier. You are welcome!
You may be some hot shot with computers (although I doubt it) but I've seen your kind come and go. I clean up the mess they leave, not because I'm smarter, faster or some hot shot computer guy myself, but because I can and will learn. Your kind won't stop and listen, won't learn something from the prattling on about all the past failures (and some successes) I've lived though. You haven't done anything of importance yet but you refuse to listen so you can avoid the same mistakes I made when I was your age.
You sir, need to read "The Mythical Man Month" and think about how software development hasn't really changed all that much. Sure, we may be coding Java and not assembly or JCL but at its core, the really hard part about software development hasn't changed all that much. Yea, I started coding procedurally in C back when K&R where still writing their book, but now doing Object Oriented in Java and C++ is really not that different. I've done waterfall development and now Agile in an effort to "revolutionize software development" but experience proves to me that there is no silver bullet. The hard parts of software development remain the same. But you would already know that if you'd listen to us old farts from time to time.
Go ahead hot shot. Dive in and beat yourself to death. We've seen this kind of thing before, heck, some of us had the same attitude and already made the mistakes you are going to make. We will just stand here and wait for you to come to your senses and start asking for help. Until then, good luck.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Although I am no longer very active in programming, I can sort of cope with people in modern-day shops with their toytown programming languages and IDEs being a bit sniffy about my assembly, Fortran or C skills, because I can easily prove my ability to code rings around them. What really gets on my nerves are the kiddies whose tech skills run no deeper than an ability to interact with Facebook and Twitter, but who seem to imagine that an old fart like me is clueless about the internet. I usually find it satisfying to rub their noses in it by reminding them that it was old farts like me who built the net in the first place.
Part of the problem is younger programmers who assume they're better because they put in a lot of effort to learn the latest GUI or DB libraries, and they know the intricate specifications of six trendy programming languages off the top of their head, and they can configure four different Linux web servers on auto-pilot. See, they're always keeping up to date!
Older and wiser programmers know that usually, to a first approximation, a GUI library is a GUI library and a programming language is a programming language and a web server is a web server. They're just tools, and while some are better than others, it's what you build with those tools that ultimately matters.
Of course, they also know when and how to check out the specifics and decide which tools are right for a given job, but they don't waste time on that until they have a need for it, which makes them less buzzword compliant in the eyes of the newbies (but a lot more productive).
When a tool isn't just a rehash of numerous similar tools before it, it's usually the older and more experienced folks who came up with the industry-moving developments, but the newbie programmers who are buzzword aggregators always trying to improve a resume and the naive managers who hire based on buzzwords don't notice that sort of thing. They don't care that someone older could build an efficient database schema that answers the important questions in an instant, or an easy-to-use GUI that customers love, or a robust concurrent server that doesn't crash and make you look like idiots in front of those same customers. Do you have at least 7 years of experience with C# 5?
Of course some older programmers really do slow down, stop learning, and coast along. It might be getting stuck in a rut and not bothering to do anything about it. It might be a matter of changing priorities, family commitments becoming more demanding and the like.
But the thing that really divides the good older programmers, IME, is whether or not they know how to take advantage of their greater understanding and better transferrable skills. If you're still playing resume buzzword bingo at 40, you're doing it wrong, not least because it implies you still look for jobs by spamming resumes like a college grad. You should be landing a good position through your network contacts before it's even advertised, transferring from wage slave to freelancer/contractor/consultant arrangements, starting your own business so you're on the other side of the desk, or otherwise avoiding being a victim of ignorance.
In short, an older developer who knows what they're doing has a more-or-less indefinite shelf life, as long as they don't play games with young, dumb people who don't understand why. As a bonus, avoiding those games is an excellent filter for avoiding crappy jobs, poor working conditions, incompetent colleagues, and low pay. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Old fart here, 20+yrs of experience, three grandchildren and still on the "shelf". I work as a developer for a Japanese mega-corp in Australia, the ~25 others who work in our department are all over 40 (except the secretary), all of them have 10+yrs of experience (including the secretary). Three of these people want to work at their projects for more than 8hrs a day, the others don't. Those 3 people are rewarded for their efforts but not sufficiently to encourage the others to do the same, they do it basically because they want to do it, not because they have to, in fact there are a few of us who could afford to retire but don't because they want to work. We are a well managed and happy crew because we know how to push back at our managers in a constructive manner, sure management would like us all to work as long and hard as those 3 people and have twice the man hours to play with but the managers are also experienced and know not to push it as an unwritten condition of employment.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
>The battle cry to unionize programmers is such a thing -- it says "I expect to be useless in the near future, an obstacle to progress of any kind, and I require collective bargaining to hold onto what I can't by skill and effort alone".
I call bullshit. You know why ? Because I first heard that battlecry on slashdot when I first started reading it, back at my first helldesk job during college in 1998.
See your disparaging view of collective bargaining is a big giveaway that you're letting your political/economic views prevent you from rationally interpreting the evidence before you.
The real truth is more like this - why is wallmart cheaper than the Mom and Pop store ? Because they can buy in bulk. They buy large amounts, so they get cheaper prices, so they can sell cheaper. That's EFFICIENCY.
Bulk always works out more efficient if you can manage it.
It works on EVERY level of the economy. For consumers collective-purchasing companies are an old and established system that works in the same way. You join an organisation, get a membership card and shops charge you less. Not because YOU are special to the shop - but because the shop has a deal with the purchasing company - "we will offer your members discounts" - the purchasing company can get those deals because it has a LOT of members - which is attractive to the store.
That's collective bargaining's core efficiency boost on two separate levels.
It ALSO works for employees. One employee has limited ability to truly negotiate his terms -hell even for executives most companies have fixed payscales (and this is true even in countries where unions aren't legal disproving the common gripe of blaming it ON unions). Why ? Because it's CHEAPER for the company. Having one standard "fill-in-the-blanks" contract means a LOT less money spent on lawyers. Simply refusing to hire ANYBODY who doesn't go along with the stock-standard contract and it's rules is a major saving on administrative costs (companies may be wrong about this but most consider it unlikely that any individual employees could bring SO MUCH value as to justify the massive cost increase and STILL be profitable to hire).
But it DOES make sense for the company to negotiate with ALL the employees. All the employees together have a bargaining power no single employee can have - AND it's in the companies interest to do it this way because it means they keep the savings of "form agreements".
Bulk agreements are ALWAYS more cost efficient. When a single entity can afford to do so, they score - but even wallmart can only get bulk deals because they have a LOT of customers.
Bulk is only FEASIBLE when you have lots of people acting collectively.
Collectively bargaining is the epitome of capitalist efficiency and every attempt to paint it otherwise is china-style state/crony capitalism in disguise. This is just as true for employees as it is for consumer-power organisations or bulk-stores.
Unicode killed the ASCII-art *