Slashdot Mirror
Ageism in IT?
Embedded Geek writes "It's hardly a new topic, but BBC is running a story about ageism hitting Gen-X, especially in IT. As a 34 year old coder, I was horrified to hear a quote from a *hiring manager*: 'In the IT sector (and coding in particular) younger minds generally work faster -- I would rather employ a keen teenager who code programs computers quickly than an older person.' It didn't help that the person is 32 years old. My kneejerk reaction, the same one anyone else over 30 would have, is that the guy is a buffoon (I'll withhold my preferred, spectacularly vulgar, term). The problem is that I do not believe his idiocy is unique - I have definitely felt the vibe when interviewing. It's frustrating, since Gen-X is finally shedding the media hyped 'slacker' stereotype only to run headlong into this garbage. Have any other Slashdot readers seen this? What is the youngest you can be before some PHB declares you fit for the scrap-heap? Other than stocking up on hair dye and botox, what steps can I take to prepare for the future? Share your war stories here." Ask Slashdot handled this topic over two years ago. Of course, this behavior could be explained away as economic concerns, as the decision to hire younger (and typically cheaper) employees can directly affect the bottom line. However, one has to wonder if the decision to go with less experienced programmers also affects software quality, in the long run. What are your thoughts on this subject?
Or a new bunch of people becoming old enough to experience it. I'd feel worse about it if the people who are starting to experience age-based discrimination weren't the ones benefitting from it a few years ago.
'I ain't a liar, baby, and I ain't proud I just want what I'm not allowed.' -- Violent Femmes, 36-24-36
Give me a seasoned vet who has the depth and breadth of experience to have learned all of those "only happens once every x years" type of lessons over some young, fast coder who has yet to learn these lessons.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Its easier to sqeeze 80+ hrs out of someone with out kids, house and a wife.
Ya know, you don't actually have to work for people of such obvious short-sightedness. In fact, I would think that hiring practices such as this would tell you the average chances for success the company would have.
US Democracy:The best person for the job (among These pre-selected choices...)
I think basically what it comes down to is quality. With the recent declines in the dot com sector, employers have chosen to sacrifice quality programmers for cheaper/faster ones.
Attaching age to that is an unfortunate sterotype that comes along with being in IT or almost any other profession for that matter.
It's the way of business.
Perhaps your luck will change when/if the economy bounces and employers have more to spend.
I have often regretted my speech, never my silence.
-Xenocrates
I think what may really be happening is that younger people can devote themselves to a subject with an intensity that older people simply don't have to spare. I know I have often wished, in my studies, that I could be eighteen again and essentially have two-thirds of my time to waste totally, instead of squeezing dribbles of time out here and there for my own projects. I certainly know I spent a lot more time studying new technology back then.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
As you get older, you need to make sure to hone your skillset so that younger, less experienced workers cannot do what you do; whether it's significant project management experience, teambuilding, extreme expertise in an area, or something else, you need to make sure you are uniquely valuable, and that your years of experience add to your value-for-the-money, not dilute it.
Managers look at ages 18 - 25 as people they can abuse. They are inexperienced so they won't stand up for themselves, and usually aren't married so they can work them 60 hours a week for low pay.
Religion is a gateway psychosis. -- Dave Foley
This is totally insane. I'd much rather have an older, _more experienced_ coder, who may be slower (tho I don't believe that to be true) than some fresh out of college coder.
As someone _in_ college, looking at the vast majority of my classmates (actually, as vain as it sounds, _all_ my classmates) people coming out of college don't have any business going anywhere near critical code. You don't become a good coder by going to school, after all, you become a good coder by writing a metric shitload of code and thus getting real-world experience.
I believe I'm so much better than my classmates because I've been doing this since I was 9, and have 11 years experience writing code. And no, I _don't_ spit out as much code as I did back when I was 10 or 11, and poured out code all day long to do whatever dumb little project I worked on then.
But you know what? I code less now, because I use my experience to sit back and think about what I'm going to code, and end up not only writing higher quality code, but less code to get the same job done, as I did back when I was a dumb little kid!
Bah, I'm just ranting now. Think I've made my point at least 3 times by now. ~,^
It all comes down to moola. You can have a well experienced older coder, and one a young kid that can code well....
First of all, the kid is probably half (or less) the cost of the older guy.
Second, you can try to lure the kid into staying in the project for a long time, thereby helping maintainability.
But on the other side of the fence, older coders don't want to be in management, so they'll always be your gruntwork force. If they wanted to be in management, they woulda tried a long time ago.
Surprisingly, though, most techies have no interest in going into management...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
There are two sides to every coin. I'm a manager of five developers and six support staff.
In my experience, younger people tend to work like dogs until it stops being fun for them. They will pull all nighters all week when you're trying to launch a product, won't need to leave early for soccer and little league games, and won't get in trouble from their non-existant wife for leaving a few minutes late.
On the other hand, older coders tend to work at a more steady pace, have fewer errors, and spend their time thinking about something before they start jamming out code. They also are more reliable at showing up on time, not burning through vacation and sick time the second it becomes available, and following through with their committments.
It isn't really fair what that manager said, but I think they might have experienced some of what I just mentioned above. Although things like that generally aren't to be said "out loud" behind closed doors you'll hear many people talking about things they have observed managing people.
What's the best solution? A balance of both, in my experience. You need an effective mix, an although young people can be great coders and older people can be off sick, those are the general trends I've seen in seven years being a manager.
You have to remember that you are there to solve your employer's problems. If he's looking at someone to produce 1,000 lines of code per hour then you wouldn't be interested in the job anyway. You want to work somewhere focused on quality over quantity, and that is probably more biased to older more experienced developers in many cases than younger folks.
Case
While it may be true that people that learn the piano at a younger age are better that one who picks it up later in life, it is also true that a person who has been playing the piano all their life is better that a young person just starting out. I think the same holds true of software. In all the jobs I've worked at recently, the younger programmers are quick to take advantage of my experience, even if they are quite good themselves. I've been programming for 30 years and I've learned a thing or two in that period. Of course, old age and cunning will overcome youth and skill.
Today is an ephemeron, doomed to the crypt of yesterday.
Other than are you at least 18, employers shouldn't be allowed to ask my age. They can't ask about my sex, race, religion or ancestry except on an anonymous affirmitive action survey. Age should be no different.
How ya like dat?
Being a fairly young IT worker, I see alot of the opposite. Older IT workers are given preference despite their experience and knowledge being similar or worse. *Especially* for any position that involves ANY sort of supervision or departmental representation.
When I was fresh out of college (a little while back) I ran into something related. My boss definitely preferred me for the fact I was youngest and he probably perceived my general energy as also being faster at programming. But I also ran into another problem. Here's an example:
It's a late Friday afternoon and we've got plenty to do, but with plenty of time. The boss tells me he wants the work done for Monday morning instead of the extra week we were originally told we had. The older developers with families told him they weren't staying late Friday, they were going home. I told him the same, but he replies, "Why? You don't have anything better to do." Apparently since I was young and didn't have any family I had no reason not to work more. I was fuming and I didn't work late. He tried to pull that crap a few more times after that.
So not only are younger minds quicker, but apparently they're also easier to manipulate and take advantage of.
Developers: We can use your help.
I'm a piano teacher, and a computer scientist.
For the most part younger kids learn piano better simply because they put in the time and are willing try new things. My adult students often progress much faster than my younger students. Its only that most adults also have complex lifes already and can't put in the time a little kid can. My adult students that have trouble tend to do so because they are afraid of the piano. I must admit, however, that some young minds can simply make unbelivable progress for no single reason other than natural talent.
I think the same thing transfers to Computer Science. For the most part if you have used computers for years you are not afraid to try things. Many adults are very afraid of computers. Kids simply explore and enjoy them.
I think Gen X'ers get the rotten deal in all of this. The generation before them WAS worse at computers at an old age. This is no longer true since many Gen X'ers have had computers since Commodore 64 or earlier. It will take another generation before this is ammended.
And for all of you programming divas just realize that programming isn't a "god given talent" and neither is piano. You simply put in the work, do what you love, and good things come from it. Don't think you are special for it, because no matter how good you are there will always be an 11 year old asian girl who is better than you'll ever be.
-Rob
When those young, fast and inexperienced coders give them brittle, unmaintainable code that soon collapses under it's own weight, they will call in us old seasoned consultants to fix the problems at a premium price.
A manager that can't distinguish quality of work from quantity has no business making hiring decisions in this industry.
Disclaimer:
What precedes is not meant to reflect generally on young programmers. There are both brilliant and useless coders at all ages.
Trouble making decisions? Just flip for it.
This is another indicator that Generation X and the Baby Boomers are spineless for the most part. Why let a bunch of 20 year olds walk all over you? Back in the good 'ol days, 20 year olds were sent off to fight wars and die by the 35 and 50 year olds. Now the 20 year olds are calling the shots.
Good for my generation, bad for humanity.
Please IT grandpas, get a spine!
Why slashdot? Why not?
The best programmers are the older ones who actually matured.
Senior members are far more respected in the field of law, because it is understood that the older a lawyer gets, the more experience they have; concordantly, the more experience they have, the better a lawyer they are.
What does a lawyer do? Pretty much the same thing as a programmer. A good, experienced lawyer will have a specialty area of law, but be able to learn about new legal arenas as the need arises; likewise, an experienced lawyer will know the ins-and-outs of a specific arena in the legal system, including exceptions and loopholes a younger, less experienced lawyer might miss.
Same goes for programmers. An older programmer, generally speaking, will be more sensitive to over-using resources, will have a better grasp of programming methodologies, and will know about many more former bugs and programming mishaps than a fresh-out-of-college CS grad.
--
I Hit the Karma Cap, and All I Got Was This Lousy
I've been in the consulting world since I was 22 (started working in IT when I turned 20). I'm now 27 and I find that age-ism is the worst form of discrimination, especially among consulting clients. Since I have a well-established beard, I usually pass for 35 and that seems to give my clients the impression that I'm better qualified than one of my peers, who is exactly at the same point in his career. All of my bosses during my consulting career have always told me never to tell my true age to the clients for fear of losing business. This is especially true since the dot-com bust when all of the "young dot-commers were shown to be the frauds they are." This deception sickens me, but I have truly seen a huge difference in terms of instant credibility and career progression when people think that I'm significantly older than I actually am. (I'm starting to get a few gray hairs, so most people now think I'm in my late 30's-early 40's. Also, I got married young and have 2 kids and this reinforces their beliefs.)
I guess the whole point of my commentary on my situation is that people do discriminate based on age and you can either play along and help yourself out (and sell out in the process) or show your true self to the detriment of your career (and possibly of your consulting company's, if you're in my shoes.) That may not be politically correct, but it's the way of the world. Also, I think that it's not as bad to play along with the game to your benefit, as long as you yourself don't start judging people based on age, picking up the habits of those around you.
Why do I h8 apple?
Well maybe they can't ask, but when they meet you they can probably tell what sex you are, perhaps your race by your name or any distinguishing pigmentation features you may have, and quite possibly a ballpark figure for your age.
The older you get the more you are likely to favor things which you've already experienced. Familiar things, while familiar, tend to not allow you to expand your mind in new ways. Yes, neurons grow faster in younger people, however scholarly old men can tell you that a mindset appropriate to intellectual growth can sustain a lifestyle of constant improvement.
Many make the choice to simply not improve in any dramatic way due to the belief that trying many different things is a childish trait of chasing fads. Whereas constantly new stimulus is very important for keeping the mind sharp.
The mind is a tool, use it as you will. And if you don't, don't be suprised that it doesn't seem to be working like it use to.
My intuition tells me that people looking to hire programmers for mission-critical applications (database, infrastructure, medical, etc.) are going to be far more interested in older, more experienced programmers than game companies or in-house applications.
:)
A young programmer might be cheaper, might have more energy and drive, and might in fact produce more code -- but they may not produce the right code for the task. If your requirements are to bang out a rendering engine so you can get your game to market before BubbaSoft, then you want cheap programmers who are desperate/naieve enough to work 90 hours a week, and if they make a few mistakes so you can see through the corners, or your weapon can be slighly embedded in a wall texture... it can be fixed in a patch, noone will care.
OTOH, if you're looking to upgrade the medical database that's been running on a VAX for 30 years, and you really need to move it to a linux/oracle system before your VMS tape gets eaten by mice... you might want someone who's been doing this for a while so the mistakes they make are less likely to cost you 5 years of records.
I'm 34 myself, and I remember the stuff I wrote when I was 24. Yes, I churned out a bit more code, but boy was it ugly by comparison. What managers should remember is that programming is like writing, or composing... the more experience you have, the more elegant solutions you can find, and the more naturally you can express them. Young people don't worry about things like maintainability, or how some other fellow is going to figure out what they did. Some do, but most don't.
Of course, that's my opinion, and being an Old Fart (TM), I might just be biased.... or maybe I just can't remember it right...
Why hire young?
Younger IT workers will often put in absurd unpaid overtime, where most older workers won't.
Younger workers just out of college will often take a job at a low salary for the experience. Older workers won't.
Younger workers are often have more exposure to cutting edge tech than older workers who cut their teeth on cobol, jcl and basic.
Younger workers have lower expectations about benefits, perks, salary, etc than older workers who can remember the 'good old days' of 5 years ago.
Older workers are more likely to have children, families, in short lives. Younger workers are more likely to drop everything and fix that server at 3:00 AM.
Older workers have seen many managers pull many tricks, know how to spot them and how to deal with them. Younger workers are generally more pliable.
=brian
Some of the bad thing that older engineers are guilty of (and please do not flame, I know I am generalizing):
Now for the handfull that feel offended by what I just said (and can back that up):
Younger minds work faster but older minds work smarter. I have both working for me and the young folks may be holding larger and more diverse constructs in their minds, but the older ones are holding well-tuned, more efficient constructs in theirs.
Programmers with experience in applied programming (multi-user online systems as opposed to single-user applications) have learned lessons and developed tricks that young minds haven't. Both types have their advantages, but there's no reason to discriminate against the 30-year Cobol vet just because he's not going to pick up Java as quick as the 2-year web-slinger. He'll show you a thing or two about efficient data processing once he figures out how to apply his knowledge to the new syntax.
They should be teamed together, if you really want to get anywhere -- the older players will want to retire eventually, and the young pups need to have a model and mentor to get their lessons in
And for all of you programming divas just realize that programming isn't a "god given talent" and neither is piano. You simply put in the work, do what you love, and good things come from it.
It does seem to me that the inherent "talent" in a person for computer science is nothing more or less than how much that person does love what they're doing. If they honestly and truly enjoy it, everything else that you would normally call 'talent' just kind of happens as a natural consequence from that..
Reading up on the IT industry, most recently in the Economist, I would have to say that that decision would kill the company.
"Wow, he thought hard about that one," you say, but I am actually refering to the belief that the sector is becoming a commodity. The industry is maturing and users want quality more and more over new-fangled products that mess up all the time. As programs and hardware get faster and faster, they are over-reaching the public's willingness to spend for speed. Instead, we are happy with an old 1 gig processor, but will pay for smart and well written programs.
So basically, if the management wants inexperienced programers, let them. They're sure to put out bad software that fails. Then these programmers will be back on the streets looking for another job, while you have found a company that excels.
One more reason to keep an eye on your money.
The shop I'm at now has a surprisingly older crowd of coders. They also have a distinct policy against hiring anyone without experience.
I have no doubt (having seen it in interviews myself recently) that there is a trend towards hiring younger staff, fresher faces, cheaper assets/liabilities. But no all shops are like this.
For the most part, I've found that places that were hit fairly hard in the past two years but are coming back, are more likely to hire experience and not just warm bodies. Your skills will come into it when they realize they don't have time to train the younger crowd.
I'm 32 now and sitting somewhere in the middle between older and wiser, and younger and faster. I'm just hoping I don't have to wind up in the market looking for a job anytime soon.
cheers
Today there are 8 year olds making happy meal toys for the latest Disney flick promotion for pennies a day. Tomorrow they will be banging out Java code on some crappy hardware 1 step up the econommic ladder from the 6 year olds out back getting toxified smelting the machines that actually don't work for scrap. One needs to distinguish themself to demand more pay. Articulate why your work is not grunt work that can go to the cheapest resources and you have real job security. There is always someone out there willing to work cheaper. There is only one that delivers the most value.
When the people fear their government, there is tyranny; when the government fears the people, there is liberty.
In IT terms I am an old fart. 46. But it seems like yesterday I was the kid who had to prove himself in a mainframe world full old men. I don't know where all the old men went, probably died of the cigarettes they chained smoked. I do remember a lot of old geeks, who although they lacked washboard abs (ageism is about sexual attraction not programming skill), they could code the hell out of anything in assembly language. Now I am old. I adapted to the Internet in 1993. I marvel what some kids do not know. Too many years on ritalin? And there's the bright ones. GenX got a raw deal, mostly because it hit recessions on both sides of college and the baby boomers before me want to deny them the same excesses in life we enjoyed. Hell we demanded beer at age 19! There is always someone who is a faster coder. There's always someone slower. Most of the times its about persistence against all odds and just getting the job done.
Didn't we just see a story about how hard it is for a kid to get into programming nowadays? Gen-X kids grew up in the eighties with simple computers that were ideally suited for learning programming. Turn the thing on, there's the BASIC prompt. Learning to program in your formative years helps you a lot. You learn how to think (even if you have to unlearn a few things that BASIC teaches you).
My first computer was a ZX81 I built from a kit when I was 12. Which meant that my first language was BASIC and my second was Z80 assembler (since BASIC was so atrociously slow even for 1982). I would POKE the machine codes into memory, and that got so tedious I wrote a BASIC program to help me do it. It started with 10 REM AAAAAAA.... You would type the assembler instruction into a field, hit a key, and it would poke the correct values into memory starting at address 16514 (where the A's started). A bunch of my friends in school did similar stuff. The occasional kid might be into that sort of thing now, but there isn't much of an incentive to learn programming now because computers are much better now and so much good software has been written already.
I bet the stream of really good programmers entering their 20s will continue for a while and then dwindle. If you spent your time as a kid playing with a GameBoy, your mind has already calcified a bit by the time you start programming.
Pianos haven't progressed to 2,000 1mm-wide keys, or introduced three-dimensional keyboards, or decided to have little-endian keyboards with the low notes beneath your right hand fingers, or added green keys above the white keys, or added a Dvorak mechanism placing the most commonly played notes beneath your fingers.
Composers haven't introduced new semi-tone notes, located between B and B-flat, or decided to portray their music to the pianist in XML format. They aren't asking pianists to play notes in 2400MHz tempo, or even to get those albums cranked out before they go home for the weekend.
My point is that computer technology has changed dramatically from the time I started learning it (1973.) And I mean really, truly changed. Yes, there are certainly technological advances in pianos, keyboards, music and notation, and I don't mean to slight the skills of any pianist regardless of whether or not they have learned new technologies. But very few of those changes really alter how a pianist plays. The changes in programming have been fundamental. Everything I learned back in the '70s has been almost completely thrown out or changed (except for one thing -- the keyboard.) If I never learned more than what I knew back then, if I didn't keep up with new technologies and new development methodologies and instead kept writing assembler code filled with GOTOs, I'd be almost useless. It's more likely that I'd be mopping floors for a living.
Younger minds may or may not absorb information quicker, but that's not really the point. If people don't keep learning in this business they quickly become irrelevant, regardless of age.
John
We work predominantly, but not entirely, in Internet services. It has to run, all the time, and when it crashes, it better log something meaningful, get off its lazy ass, and get back up and working yesterday. Young kids who have little to no professional programming and development experience don't know much at all, if anything, about fault tolerance and high availability. Nor do they usually fully grasp the importance of error checking and reporting, defensive practices like design-by-contract, CM, QA, etc. I want folks with battle scars. Occasionally you find a youngin' who's dealt with that already, and they work out great, but most haven't.
Now that's not to say that I wouldn't hire a youngin'. I'd hire a recent college grad with at least some of the prerequisite skills and a good attitude to start off with maintenance work and small projects. For example, fix some bugs, do integration testing and explain why the bugs are bugs and what caused them. Sooner or later they can actually explain what happened and how to fix the problem, and then they're off.
As for learning ability, I, frankly, haven't noticed a real difference in the ability to learn between the young and old when it comes to languages, specs, etc. If anything, I've seen older people pick stuff up faster.
My father started going gray at 16 and was completely white haired by 21. I started going gray at 18 and have the hair color pattern of someone in his late 40s in my mid 30s.
It's a genetic condition. It doesn't fit in any sane category of disability but it does throw people's estimates of my age off by as much as a decade.
Something to think about.
Yeah, because all the experience those old grizzlies at ID have from working on game engine after game engine sure hasn't helped them, any.
My Greasemonkey scripts for Digg &
What you say is true -- on the average. However, individuals deviate from the curve.
Also, there is a fallacy there about the biological "fact" you cite. You give no numbers. You imply that after 35, a person's cognitive ability drops so dramatically, so quickly, that they are unemployable compared to the non-impaired yunguns.
Actually, on the average, cognitive ability drops in a slow, sloooowwwww curve that takes decades to really show a difference. The difference between a 20 year old coder and a 35 year old coder, brain-biologically speaking, is damned near non-existent. Actually, since the 35 year old has 15 more years of experience, his brain can smoke, char, flame, annihilate and flambe the 20 year old.
The real fact is that the 20 year old will never acknowledge that the Old Guy is smarter. The difference between the 20 and 35 year old is how each of them (and the management!) judges ability.
A 20 year old, to keep to the stereotype, judges acuity in the abilities to keep up with trends, chat, game, and all the other things that he finds important. Since those things are not important to the older person, they can never measure up.
The 35 year old, however, measures acuity in more than just being current. They have seasoned judgement, perspective, and have witnessed a lot more pain than the kid has.
When I was 20, I never would have believed any of this, but having gone thru the wringer, I do have the perspective to understand what is important, and what is trivial.
Back to point: your biological fact also omits that the decline after 35 is for the population as a whole. Fallacy. A person who thinks for a living keeps their faculties sharper longer. So a coding 35 year old is a lot sharper, in programming, anyway, than the average 35 year old is.
It's not about having a quicker mind, I know plenty of people who are in the late-30s, 40s, 50s, etc who are plenty sharp and on the ball. Having a wide experience base gives you more to draw from when envisioning a solution.
What I found out from several of the companies I've worked for is that they don't want you to have a bunch of social ties and responsibilities. Have a wife, kids, or aging parents? Don't call us, we won't call you. We'd rather hire someone who's brand-new in town with no social life and that we can work 80+ hours a week until they burn out. This is a technique that's been employed by the likes of MCI, Qwest, Enron, WorldCom, etc.
They don't like people who are older because we are typically married, have kids, and aging parents; all responsibilities that take time away from the 80+ work week. It also means that you have experience and typically want more money. Again, they'd rather hire 2 22-year-olds at $30K/year each rather than spending $60K on one person. 160+ hours of effort a week from the youngsters, or 40-60hrs/week from one person with family responsibilities? Which do you think a company would choose?
Is there ageism in the IT industry? Yes. Is it going away anytime soon? Hopefully when the corporations realize that experience counts.
If "disco" means "I learn" in Latin, does "discothèque" mean "I learn technology"?
I think the idea that younger minds are better, faster, more flexable, etc., is simply a smoke screen. The issue I've run into is that I can't compete salary wise against younger kids. I need to make at least $4,000/month, but someone right out of college, with no wife and|or kids might be willing to work for $2,000/month.
-- Galen Rhodes grhodes@the-chatter-box.com Journal: http://journal.the-chatter-box.com/users/grhodes "Consistency
I think the reason they go for the young ones is they can pay them less. People are generally cheap.
I'm 40 years old and the oldest person in my dept. I was the oldest at the last gig I had and the oldest at the gig before that. Before that, I wasn't the oldest. There were a couple of the battle scarred coding vets working there. You know the type, the guys that THINK in 256bit encryption?
Since 1996, I've usually been either the oldest or darned close to the oldest in every development company I've worked for. I wade through the hoardes of 'fresh outs' to get to my cube. These inexperienced kids are talented, but they have a tendency to believe they know alot more than they do. I've found that I usually have a much broader and deeper experience than these kids, even though I wasn't able to finish college for financial reasons. Sure, there is the occasional WunderKind, I'm just generalizing about the typical early 20s hiree.
How to prepare for this? Good luck. If people perceive you as an old mare ready for the glue factory, there's little you can do. Your possible options include dealing with it as best you can, forming your own business and changing career to something less generationally discriminative.
Sure, an older person can pick up the ability and wield a certain prowess and even artistry. But no one, to my knowledge, would argue the fact that a person who learns to play the piano in childhood has a certain "feel" for it that people who pick up this ability later in life can never attain.
Your analogy is incredibly off the mark. The question is not "does a child learn faster than an adult", but "is a person who learned as a child, and is still a child, better than a person who learned as a child, but is now an adult with decades of experience?"
I took my first programming class when I was in the 6th grade (about 1968) and haven't stopped since (picking up a computer science degree along the way). I'm 47 now, which is about 300 in programmer-years, and I'm pretty much unhirable, in spite of the fact that I have spent something averaging 2 hours a day for the last 20 years on nothing but learning new stuff (that's in addition to putting food on the table USING the old stuff.) RIght now I'm making enough to get by doing contract work, but my chances of ever getting on with any large company (let's say any company that actually has an HR dept) are ZERO. And that sucks.
To ensure perfect aim, shoot first and call whatever you hit the target
With all due respect to Andy Hertzfeld, he probably didn't have nearly as much to think about when he was younger. By the mid-40's, the average programmer probably has a family (with birthdays, soccer games, tuitions, recitals, etc.), 1 or more mortgages, a stock portfolio of some sort that's only now getting the attention it really deserves, some insights on those political issues that were so unimportant before, some project management and perhaps budgeting, a health condition or two just starting to require some real attention, etc.
What the average 40-something has to make up for all of that is some perspective on what makes the most efficient code and use of his/her time, a deliberate pace of work, 20 years of experience, less emotional drama, maturity, stability, etc.
I'm a flight instructor, and it's easy to see where the illusion that young people learn better/faster comes from. Despite the popular notion of today's youth, they're not as cynical or as questioning/probing of your instruction as adults are. As an example, if I tell a 16 year-old kid that when you bank the airplane to the right, there is an initial yaw to the left because of a phenomenon we call "adverse yaw," he'll probably say "OK" and correct for it on the controls. If I state it so simply to a 40 year-old student, he'll ask why. So who has learned it better? The kid is immediately compensating for its effects, and is flying the airplane properly a bit sooner; but does he know why he's doing so? The adult understands the reasons behind the correction; but has delayed implementing the knowledge because of the time spent questioning.
Over the course of learning any complex task, these moments add up to a perception that the adult isn't learning as fast or as well as the younger person. In fact, they are. You simply have to tailor your training and your expectations for the difference in approach.
Hot Damn! It's the Soggy Bottom Boys!
All I can say is - after ten+ years of programming experience (and that's just industry, not counting the stuff I did in college and before) I'm still telling some people what hashtables are. And they were around before I learned to program.
At the most basic level, programming is the same as it was thirty years ago. You can just do more with it, is all.
How programs interact is not even all that different, just mechanisms moved into different worlds.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It's changing. There was definitely some bias, but it's switching, and in a few cases, reversing.
First, in the downturn, the older more experienced programmers come cheaper.
Secondly, despite all the changes in technology, older people come with a valuable knowledge of history. I recently had to solve a problem with scripting that someone without my experience wouldn't even have an inkling of.
Third, older people come with broader knowledge. That is making a lot of difference over time. I've noticed more experienced programmers also fulfilling analysist niches while they code, drawing on their knowledge.
Fourth, older people come with more diverse knowledge. On my last job search, half the time my interviews started with questions on non-technical skills.
Fifth, you can hire a code-only person. That's fine. You can also outsource them to another company or country. It's easier to outsource a year of experience than it is ten years experience.
I don't see as much ageism, and my guess is it's going to decrease over time. I'm in my 30's and I work with many people my age or older.
Just my 1/50 of a Euro at current exchange rates.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
Yeah. My thoughts exactly. The younger coders tend not to think about design or the overall problem. They just get the stuff working, and not worrying about issues that may come down the pipe later on. From what I have seen in college in the past, most people don't spend time on design. I myself was guilty of that: code first, design later. Not any more though when you realize that you spend significantly less time in debugging if you have a good design lay out in front of you. Coding/syntax is all just secondary. At least that is my personal philosophy toward programming...
...the decision to go with less experienced programmers also affects software quality, in the long run.
Yes, it does. Period. Young'uns are more likely to choose immature tools, more likely to make predictable mistakes, more likely to jump on whatever bandwagon started rolling last week, and on and on.
If you wanted to assemble a great symphony, you don't interview at the mall record store on Saturday night. If you want to build a bridge, you don't go to the day care and see who has a knack for Lincoln Logs.
Seriously, kids graduating from college are more like that toddler with Lincoln Logs than most of us would like to admit.
Healthcare article at Kuro5hin
That's the only education aside from computer training listed on my resume.
;-)
My comeback when people ask about it is that I've never been to college, but I taught it for a few years. (true story)
Diplomas are nice, but when the rubber meets the road, they don't mean much. They're mostly a tool to see if you have any of the experience/ability you claim. Without it, there's other ways to demonstrate your ability.
Actually, any company that would toss a resume because it didn't list college experience isn't a place I'd want to work anyway- not sour grapes; it shows a fundemtally flawed methodology that probably permeates the entire organization, and it would be better not to be there, in my opinion.
I'm 37 and have been in IT for a dozen years or so, but programming for about 20. I'm in charge of providing standards, best practices and technical support and advice to 250+ developers.
It's not how many rings there are when they cut you open, it's how well you can navigate the technologies. I don't just people on how many languages they know or even what technology they are proficient in. For programmers, it's what their problem solving skills and adaptivity level is when the pressure is on or something challenging is presented.
Software skills cannot be measured by number of years. I know coders that are 17 years old that can dance circles around me while at the same time others in their age group that couldn't assemble their way out of a paper bag. The same for the old geeks like myself. There's good and bad everywhere, it's just a matter of being able to sift through the silicon jungle and do what you're best at.
I'm 38 and have been hacking/coding since I got my first C64 and Timex Sinclair. I now write smallish business/accounting apps and even though I may have slowed down a bit, I'm still way more productive than any of the wiz kids around me. Yes they code faster and yes they catch on to new things quicker, but they haven't got a clue how the world works. They can't write stuff that is user-friendly, they can't present their ideas in a resonably inteligent manner and they can't deal with the general office worker. They can't anticipate how a less-informed office person will mis-interpert their terminology and layouts. They can't imagine that a general office person doesn't know when to single click and when to double click. They can't create a consistant interface without serious bitching.
If you want a game engine, a kernel, a driver or anything that doesn't require the code to interact with a human directly, then hire a kid. If you're writing software for humans to use then get someone old and crusty.
G
We're still working with Von Newman machines, with (roughly) the same architecture that Charles Babbage described around 1850.
I've been programming since I was 8 years old (I'm 26 now, that's 18 years of experience), and I feel confident that I can program in any language, paradigm, or technology. And not because I know every technology out there, but because I finally grasped that programming has nothing to do with computers at all!
Programming is not about knowledge of a particular technology or set of algorithms. It has more to do with a particular form of abstractions you build in your mind.
Learning how to do that took me a long time (almost my whole life), and I still have lots to learn.
What you must find in a programmer is that ability to create an abstract representation of a complex problem.
A younger programmer might find it easier to write the code immediately, but probably he will produce twice the ammount of code necessary for the task, with at least twice as many bugs.
An experienced programmer foresees problems that lie ahead, that might pass unnoticed to the novice.
So, bottom-line, the secret of success lies in experience...
I'm not saying we don't employ an army of COBOL programmers to maintain our old stuff. We do, and many people still have those jobs. But COBOL programs themselves are being phased out as new technologies move in, and many of those COBOL programmers are now learning Java so they can maintain employment. The army is shrinking. I think COBOL programmers are now little more than niche programmers.
As a matter of fact a buddy I had lunch with today (a COBOL programmer turned Websphere developer) was complaining that he was one of only about five people in the company who still knew CLIST (a scripting language for TSO that was popular in the 80's.) I'll tell you right now that skill has no value: if no one was left to fix that CLIST, we'd just be writing a modern replacement. It's not worth learning or porting. Old software will die, and I think that as replacements become easier to develop the end will hasten accordingly.
So, we can sit here and complain that "kids these days don't even have to know hex in order to program," or we can recognize that the world is changing and keep up. I'm worth having around today because I've kept up, not because I've spent 30 years sharpening my mad assembler skillz. You can argue that underneath it all it's still just ones and zeros, but as an industry we've moved way past that.
John
The piano analogy works. Your dissection of it does not.
I can guarantee Beethoven never had a piano that could summon the sounds of a thousand instruments and provide ultra-realistic playback of them, variable tone and pitch generators, MIDI, stored memory of common chords playable at the touch of a single key, co-ordinated multi-tracked polyphonic doodad-this and that, and I'm sure there are some programs that will interface with written music formatted in XML, feed it to a keyboard and back again and let the composer do as he pleases.
Some could argue your point and insist that computers haven't changed all that much. As far as I can tell they still have cpu, memory, storage, input and output. They still require at their lowest level machine instructions to do anything useful. Sure there maybe programs and techniques stacked on top of that, that isolate you from having to type in and manipulate all those ones and zeros, but at the core computers haven't changed all that much.
Fundamentally, the principals are the same for a younger or even older programmer... input -> process -> output. Same for a musician, input -> instrument -> sound. Pianist and programmer still have the same keyboard, all the stuff behind it has been swapped out, and yes, now the input and output is slightly fancier. However, fundamentals of making programs or music remains the same, regardless of how sophisticated your instrument of choice, you can still make beautiful music or absolute noise.
Talent will determine how quickly you can make something resembling good output or music, experience on the other hand seperates the men from the boys when talent (gasp) is equal and is the real point of this article. The other point of the article, is that there are still stupid people in charge of hiring smart people, The stupid people could do there job correctly if perhaps they had some guidelines of what is illegal or not.
So your other point is, you can't sit with thumbs up your ass, and expect to keep in touch with the latest and greatest and be considered valuable. Please, point to another business where this isn't so?
No.
I once worked a on large programming project where there was a big shift to move from an old style legacy codebase into the latest fashion of object oriented programming.
All the developers from the old project knew a lot about what the new project should have in the way of functionality, etc., but were not familiar with the intracacies of C++.
Younger people had spent their time learning the latest languages like C++ and so were in a position to write the new code, but they were not as familiar with what exactly the old code did (did well, did poorly, etc.)
Consequently, the project ended up winning some and losing some. It uses some recent sophisticated programming techniques to achieve, well, less than it could.
Obviously, what's best is to have both quick, sharp, uptodate young people and wise, experienced old people and to have them working together and communicating a lot to each other.
Discriminating against either the old or the young will set you back one way or another.
"Provided by the management for your protection."
make the same mistakes you did yourself or wisely learned to avoid committing in the first place (usually by learning from somebody else's disaster.)
Some are painfully obvious to me but the PHBs and the co-workers have blind spots that just means that everything that I (and they) do is fundamentally flawed, undocumentable, will be a hemmorhoid to maintain and get trashed because it deserved to be still-born to start with.
Having a system designed by "people who knew" using Objects With States, but implemented by a "crew without a clue" who don't understand a thing about State Transition Engines, leads to duplicated, inelegant or just plain f*cked up code. When its gets to the GUI, its painful, just painful.
At least they pay me the little bucks and I eventually learned to just shut the f*ck up.
I just make sure to take my own advice whenever I can and write my code as well as I can. And when I have to pull off a real hack, I appologize in the explanatory comments.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
There is some truth to the offending statement - but the statement itself is myopic.
It is true that younger techies work faster. It's obvious that they should, really, for the same reason that 16 year olds get more traffic tickets than people twice their age.
Us "old timers" have a decade+ of experience upon which to draw. It is true that to a degree the advancement of technology has mitigated the need for some of this experience. However, we are not automatons, and have abstracted the lessons we learned on old technology into general rules that apply in the modern context as well.
(Oh God, I'm actually making a "back in my day" post. Shoot me now!)
Anyway, kids do run fast around corners and such, because they've not fallen over very much, yet.
Now lets go and ask the HR drones who think this way about the amount of rework that bright-eyes and enthusiastic go-get'ers create. Let's talk about solutions that are not maintainable, and about implementation strategies that don't scale, that do not tolerate creeping features with grace.
There is a reason why jobs demand a degree, and there is a reason they demand "x years experience". Kids make great cannon fodder, in IT as well as in the military. They consider a death-march glorious, and have no wife or kids to rush home to.
But would you let a green officer, even from West Point, command your army? Would you send them on the elite and covert missions? If you would, you'll soon be flying someone else's flag.
Same with IT. If you choose the gung-ho, do-or-die punks to bring your mission critical product to market, you'll soon be sporting someone else's logo on your letterhead.
Kids have their place in IT. They can code like hell, and there is much to be gained from their stamina and fearlessness. But they need to be given clearly defined and well-contained tasks.
Hell, most of these kids can't write "Hello World" without the aid of their favorite IDE! Sure, they learn and grow and get wiser. But guess what?
By the time they've learned, grown and won their wisdom - they've become US, the old timers, who work slower, because they know better.
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
However, one has to wonder if the decision to go with less experienced programmers also affects software quality, in the long run. What are your thoughts on this subject?
As a younger coder, I can tell you indeed it does afdfect it. It makes it MUCH BETTER (assuming you hire decent younger coders). I have worked with both younger and older coders, and to my experience the younger people design better, make more well throught out designs than their older counterparts. I think this is a result of older coders growing up with all the functional languages likc C et. al, and have a hard time wrapping their mind around the OO concept. They then use OO languages to write horrible code, because they do it in a procedural fashion. younger people, who "grew up" on OO, have no such problem, nor do they have a problem with procedural type problems, because theyr emerely a subset of OO.
The main problem with older coders I find is they are too set in their ways, and never take advice. Especially not from a younger person.
... in the hiring managers statements is this:
- The salary demands of a younger employee is going to be proportionally less than the salary demands of a more experienced programmer. Therefore younger = lower cost
- The younger programmer will not at first bristle at demands to work unusually long hours to get a job done. The more experienced person will question the need for working longer hours.
For a quality product there is no substitute for experience. Companies now are not looking to produce a quality product, simply a cheaper one.
Believe in things of which no person has ever learned
You also forgot...
Are you as pliable as the 20 year old that I can push around the office and have him do my bidding at a drop of a hat. Being young tends to open ones-self to intimidation from those more powerful and experienced. Especially managers with a bit more political/behavior leverage that they've learned over the years being a manager. Getting older, one hopes to learn how to read, understand and discern certain "tricks" of the mind. "Resistance is not only futile, but does not support my agenda."
Being fresh out of school, discipline is still fresh in their minds. As much as you may argue that youngsters are reactionary to authority, those that start applying for real jobs generally have accepted it by the time they get to that point.
"Last one in is a rotten goblin!" - Kepp
Yes, you can have old fuddy duddies who don't learn.
But I've run across far more "rigid thinking" from "youngsters" than from experienced baby-boomers. Good engineers with decades of experience have seen many ways to do things, remember when all of these ideas were new, and are willing to try new ideas quickly.
Bad engineers aren't worth hiring no matter what their age or whether they are "cheap".
So fundamentally, any engineer who stopped learning when they left college should not be hired or retained. Even if they left college last year. An engineer who has been learning for 10-30 years obviously is going to be a better buy than an engineer of the same raw skill who has only been learning for 5 years.
I agree that there is an undertone of negative vibes when interviewing or being interviewed in IT today. I just left my position as Chief Technology Advisor for a billion dollar international oil company and I am one of the unique. I am a 29 year old female. (And I *worked* my way to the top.) I spent many nights on planes travelling overseas where my best friend was my passport and a roll of handi-wipes...just in case they were sending me to a place that had not yet heard of the invention of Charmin.
I have been exposed to the IT industry for over 20 years as my father was in the field. I remember punch card tabs being the coolest thing to play with! Now that I am a bit older and my father is 56 yrs of age and still maintains his skills in the industry, I can see a deffinite bias towards those of age. Any reference to age, such as highschool and college graduation, has been removed from his resume. Now he is receiving more responses than ever. Before he did not even deserve a, 'Thank you, we're not interested,' letter. I, on the other hand, receive calls, emails, and requests from companies on a more frequent basis. And I feel it is because I am younger as our qualifications are very similar with one minor detail, he has far more experience than I.
I have worked with, interviewed, hired, fired and let-go many a skilled IT resource. Therefore, I can say with some degree of certainty that age DOES make a difference. As you get older your priorities tend to change. Gone are the nights that you stay up all night until the wee hours with your buddies partying, playing LAN games and ordering pizza for dinner. (And reheating it for breakfast and lunch the next day!) You'll work all night if you have to because you love to code. This is a plus to someone such as myself who is ultimately responsible for the output of said code and project. But here is the problem, jsut because you are older, does not mean that you do not work to get the job done when needed, in my experience it has been that you tend to make less mistakes or have enough experience to code more intelligently and therefore, can go home sooner.
However, I fast found that the myth of 'younger is cheaper' is just that, a myth. I was lucky enough to work with several people who were older than I, though I was their supervisor, and I would not have the project run any other way. I had a project that was slated for failure come in on-time, under-budget and with extra bells and whistles that the client loved and consequently, hired us to do 10 additional sites in their overseas offices.
The reason? Because the resources on my team were older, wiser and faster because they knew the sound short cuts that could be made and have a successful product in the end. There was no guessing or supposition to their architectural understanding of the task at hand. Only some with experience could do that on a regular basis. So by extension, these resources were less expensive in the long run.
If I have a new developer, how long and what will be the TOTAL cost that it is going to take one of my experienced developers or Team Leads to help them ramp up? How do you teach a young developer how to test why an application is breaking by reviewing hundreds of lines of code with no comments, quickly, efficiently and above all intelligently? Experience will pervail time and again because they have been through this type of exercise time and again and know what to look for first.
I am not saying that fresh starts and young minds aren't a positive thing to have in a company. For this you create a sense of longevity and a new round of knowlege transfer capabilities in a company, but who is going to transfer this knowledge? Other teenagers or college-age kids who are just learning your company as well as technology trends and development skills themselves?
One argument a colleague of mine brought up was that the technology that is available today, i.e. Java, was not available when my father was going to school so we're all starti
"We're still working with Von Newman machines"
It's spelled von Neumann.
As one ages, one becomes wiser.
Maybe when you reach the age when being a 'code-monkey' is to your disadvantage, why not just do something new? Carry your expertise into a career as an independent consultant or work on small programming projects for companies (as an independent)?
I know an independent consultant and he's in his mid-thirties. Hes very bright and I (at the age of twenty) work at a similar pace when we collaborate. Of course I still come up with all the good ideas!
People do have more piece of mind when they percieve they have a more competent person in their corner. His expertise is why he's so valuable. He's also well educated, but charges $100/hr for such things as creating access applications.
There are a few facts in this whole controversy that are being overlooked.
First for many years now employers have sought out young techies. The stereotype of the young
man with an earing and a ponytail. That hasn't gone away. Been with us for close to a decade
now.
Second IT burnout is a real issue. Especially with Microsoft products where what you learn
changes with such frequency. So many of Microsoft's "initiatives" flop and are quickly replaced
with yet another grand scheme of doing the same task. I've lost many months learning
technologies that were never widely used.
Since moving into the Linux world I find that while there is constant change and growth,
the change usually has a purpose to it and that I spend far more time enhancing my skills
than relearning the same thing over and over again as I did in the Windows world. This
has helped me stave off burnout. There are so many technologies out there. Some change
quickly, some barely at all. COBOL programmers probably see the most static environment
of all major IT positions. Still you have to deal with COBOL. That is probably
punishment enough.
So it is not so much a question of young mind versus old mind. It is more a question of
how many times can that same set of synapses be reconfigured to implement a logical task or to
find a commonly used tool to configure something.
Thus for a Windows programmer age is very relevant. A twenty something Windows programmer
hasn't been through Quick C, Quick Basic, Foxpro, Access (every version is completely
different it seems), Visual Basic, Visual C (1.5 to 4.0 was almost like changing
languages) J++, VB Script, Active X, DAO, ODBC direct, RDO, ADO, and all of the other
million things that change every week.
DBA's however see far less change in their work environment. Age gives them little
disadvantage while experience gives them huge advantages.
Factors that are platform and position independent include.
Younger programmers work for less.
They have not been Dilbertized by the Red tape and complete lack of common sense displayed
in so many companies today. Young people often actually believe there is a purpose to what
they are doing. That it will make a difference and earn them promotions based purely on merit.
So in my opinion the IT sub-category and platform are very relevant to the issue.
Many IT positions are high pressure high stress positions. Stressed animals of any
sort exhibit poor learning skills. When a person works 60 hours a week, spends 10-20 commuting
and still has to deal with normal life issues such as bills, friends and loved ones. There is
only so long a person can do this before the efficiency starts to degrade. Before the love
of technology becomes only a warm soft spot.
One thing that IT has in common with artistic endeavors is that you have to love what you are
doing. Few make in our field that are in their job purely for a paycheck. Do you see factory
workers building miniature factories in their homes? Do you see road workers building roads
in their backyards? Do you see accountants setting up accounting systems at home for the
pure joy of it?
Most IT workers go home and play with computers at home to a greater or lessor extent. IT is
and art and a craft. When the love goes away you will be far less efficient. Just like a
musician who plays on after the love for music is gone, an IT professional who is stuck in the
field will produce far less than one that still loves what they do.
Anybody can learn how to play an instrument. Anybody can learn how to program. To do these
well does take a certain knack. More importantly it requires a certain obsession. To be
passionate enough at one point to live to learn the task. It takes that to be good at a
craft or an art. Natural talent helps. Anybody can play guitar but thirty years of practice
cannot produce Eddie Van Halen like solo's. Thirty ye
you're assuming that people that don't continue to learn throughout their years of programming. you can't do that. even the best pianists have kept learning for more than 20 years. i know someone who has been playing for 10 years. she's going to school right now for music. she's still taking piano lessons as part of her education. her piano teacher is a phd student, still learning how to master the piano. i'd be willing to bet that this teacher has been playing for 15-20 years. even with music, you learn new ways to make your job easier and to become more skilled at it. you learn different techniques to playing the piano or any instrument at that. these new techniques are not necessarily easy to pick up so they aren't taught right away since even younger kids want to be able to play songs to say they know how to play music. those who are really interested keep up with it and learn the new techniques so they can play more difficult music and those with even further interest learn more techniques. and these new techniques will help you learn how to write music and improvise and make great music. so just playing a piano really well isn't all there is to being a great pianist. there's also the ability to understand music theory and all the other aspects of music. you train your ears to hear things so that you can make it sound better.
as for a programmer, their mind is trained to think of how to go about solving a problem. they learn new technologies to make their jobs easier, they learn new languages for different aspects of their jobs. their instrument is the computer. all they are doing is giving it instructions on how to do something. technology has not changed all that much. sure things seem very different from 10 years ago, but are they really that different? let's even say 20 years. still not all that different. programmers and other computer people just expand their knowledge to utilize their instrument more effectively and more efficiently. they do this the same way a musician expands his knowledge to utilize his instrument more effectively and more efficiently. there's more to a piano than just playing music. pianos are used to write music and make music, not just make sound. i'm not knocking your profession, i wish i knew more about music than i do. i'm just saying that your analogy is very flawed in that you don't take into consideration that these programmers learn new technologies just like you learn new techniques and theories. unless, of course, you just play music and don't worry about all the other stuff involved (arranging, transposing, composing, etc, etc, etc).
please me, have no regrets.
Hi!
One of the challenges of any media business is producing a constant stream of content. If, for instance, SlashDot only put up two or three stories a day, far fewer people would read the site--and they'd have far fewer page hits on which to place banner ads.
BBC Online has exactly the same problem--they have to (in industry parlance) "feed the monster" to keep readers coming back. In interactive media, like SlashDot and BBC Online, they can't just post stories--they really need to post stories that will prompt readers to add comments. (That's why 'red meat' stories like Microsoft cheating on the antitrust deal get posted, and obituaries of Internet pioneers sometimes don't. The Microsoft stories generate all kinds of traffic.) The web site has a continuing need to come up with stories that will generate a lot of interest, generate user comments, and generate a lot of traffic.
Think of it as editorial trolling
In effect, the editors of BBC Online are trolling. Editors and producers keep lists of story subjects that can be dusted off and run any time--even if the subject has been covered before. They're called "evergreen stories" because (like the trees) they never change from one season to the next. I've worked at one of the major television networks in the U.S., and I've seen the whiteboard listing evergreen stories--including "new concerns about Internet security," "Internet dating--is it for you?" "Internet dating--these people found romance!" and a bunch of others. "Age bias among computer programmers" is just another evergreen story that can be run on a Friday afternoon (typically the slowest news period of the week).
Is there any truth to this age bias notion?
Read the article critically: the article, and the "study" on which it reports, are based on anecdotal evidence. (Even when the study throws statistics around, the stats are based on what people told the researchers.) There is anecdotal evidence that Martians landed in Roswell, New Mexico--which is a far cry from saying there's any real proof. While somebody looking to cry "the sky is falling!" can quote anecdotes of people who can't seem to find a job after taking a class, there are plenty of us old folks out here making a buck.
A little anecdotal evidence...
Case in point, me. I'm 44, mostly bald, with quite a bit of gray in what hair is left. I'm working on-site for a local client, with a team of 18 programmers whose average age (including the summer interns) is about 23.
The anecdotes suggest that younger coders are more productive; they write more lines of code; and that they are willing to work longer hours. Nope, nope, and nope. The hands-down champion code writer is an embedded guy who manages during the day, and codes at home all night. The absolute go-to programmers on the team are all in their 40s. And when the project was in crunch time, those same 40-somethings (including me) were the ones staying late, putting in the time, grinding out the project.
The kids? Hey--they have dates. They have plans for the weekend. They're generally (not always) gone at 5:30. They can spend all day asking questions before they write a line of code--and we have to carefully review their code before we release it into production. The old folks on the project are the acknowledged experts on the language--and we're using C#, which only appeared two years ago.
I don't mean to dump on the young people (and several of them read SlashDot). Several of them are extremely talented. But the older developers are much more comfortable working with new tools and platforms, much more experienced (and relaxed) working in a high-pressure environment, and are much more capable of sucking it up and delivering when it's crunch time. We have been there, done that, and will do it yet again.
And yes, Virginia, we get paid a lot more.
Simple things like:
- Thinking before you code - 'cause you know from past experience that it will not only be faster to implement the same functionality, it will also have less problems (uncovered bugs) in the future (guess who usually has to fix the bugs) and will be more easy to adapt when (not if) the requirements change.
- Finding out that most problems end up being variants of stuff you've done or seen in the past - different names, different industries, different languages and still the same patterns appear behind problems (and solutions).
- There is NO language, development methodology, OS or whatever that is right for all situations - there is no silver bullet, different things have different strenghts and different weaknesses.
- No mater how much you know, you can always learn something new from someone.
... (there's a lot more)
Anyways, i've recently came to the conclusion (by once again being face with people that should know beter but don't) that most IT professionals seem to be stuck at being Knowledgeable (Answering the Hows) and never to grow to become Wise (Answering the Whys) - this has beem pretty disapointing to me, so forgive me my rant.By the way, wisdom comes from experience but age does not necessarily implies being wise.
It is hard enough to get an interview with University Education listed on your resume. There may be other ways to demonstate skills but not having a University Education will likely get you cut from 90%+ resume piles and without an interview you can't demonstate skills.
When someone has to look through 1500+ resumes for 2 positions there are a couple givens.
With that many resumes there are surely going to be enough qualified candiates to fill the position.
Any easy filter you can apply to elminate people will be applied. I can tell you that education is a quick look filter. Gets rid of the people that are unlikely to meet your qualifications.
Sure if everyone had infinite time to select candiates they might take a closer look at each person but we are working in the real world where people get paid for their time. You might miss a few people that might be qualified for the job - perhaps you would have the skill set required but in the end it isn't a big deal because some of the other candiates are going to have similar skill sets.
I don't really see how this is a fundamentally flawed methodology. It just isn't practical to not apply some quick filters when you get stacks of resumes for positions.
The resume secrets, straight from a friendly teacher I knew that spent about 15 years in HR:
;-)
- #1: KISS
- If you have something you want to say on there, but don't think it needs to be obvious, it doesn't need to be on there at all.
- Don't listen to ANYTHING a high-school counsellor has to say about resumes. They're great if you want to cut someone's lawn, but seeing a whole section on "interests" is an INSTANT trash mark, even if you list rocket science.
- Whitespace is nice.
- Big type is nice -- don't make the guy put on his glasses.
- Expensive paper is a big plus. Try some paper with cotton.
- Don't forget good contact info. Ever. Include Phone (Home + Bus), Fax, email, ICQ, Telex
- Send it to the RIGHT person. Spelling their name wrong is an instant roundfile.
- Diplomas, etc are very important, but if they aren't from respected places, they won't mean anything.
- Experience is also VERY important for most jobs.
- References are important, but rarely get phoned (and if they are getting phoned, it means you're being considered seriously already, which is good).
- Customize the resume to fit the job. A graphic artists resume should look visually appealing. A draftsman's essay should have everything lined up perfectly. Beats me what a computer guy's essay should have on it (Chocolate bar marks and pizza grease stains? Printed on an impact printer?)
- Use a nice envelope and don't be stingy with postage. DON'T EVEN THINK of using your current company's meter to stamp it. INSTANT ROUNDFILE.
Using the above rules, that teacher kept his HR job for 15 years and barely had to do any work... He threw out something like 50% of the resumes without even opening the envelope (if you're so cheap that you steal your company's postage to send your resume, then you're too cheap to work here).
Just some suggestions.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
congrats on your attitude its the right one.
However go to any HR and ask around. They have their own little world of what matters. Many orginizations have this and they do not even realize it. They get their marching orders and they will blindly go forth and add new ones. I have seen it happen MANY times. Even in one place where I worked we had 4 different HR people. Each one with their own idea of who to hire. This little group has more influence on who is hired than you think...
You know, I'm an engineer, and I'm not really good with a slide rule. I know the principles behind one, and I know without a doubt that if I needed to learn to use one, I could.
I do know how to use many more capable tools than a slide rule, and I've spent my time mastering those rather than a slide rule.
A good engineer knows the tools necessary for the job. They know that they can add more tools to their set if they need to, but they don't learn them for their own sake.
If assembler is important, learn it. But it's not important for its own sake: only as a means to an end. If that end is better served by other methods (which require less work) do that.
Why yes, I AM a rocket scientist!
The fact is that there are many candidates to choose from for any open position, and hiring managers are always looking for one way or another to eliminate an applicant based on any concievable characteristic regardless of the likelihood that characteristic affects the ability and commitment to getting the job done.
How wrong the concept can be is easily shown by the record of a person I used to work for, John Fenn.
Now John is a little up there in years. He's 84 or so years old. John's mind however is as active as anyone 1/4 his age. Plus he has great enthusiasm for his work, and a tremendously broad experience to draw from. John's current employer offered him a job when his last employer forced him out.
Now John's new employer has found itself with a great deal of prestige, because John was awarded a share of the 2002 Nobel Prize in Chemistry. For work he did while in his 70's.
If you judge people's capabilities based on age, you are making a HUGE mistake. Those 20-somethings? They haven't proved that they are capable of anything but littering a source code repository with crap. Now that 40 year old coder? Do your think he would still be coding if he didn't enjoy it? Or wasn't succesful at it? Chances are that 40 ear old coder has turned down promotion to management a number of times - he enjoys coding to much to leave it.
Remember - Albert Einstein turned down opportunities to be head of the IfAS, and the first President of Israel for the simple reason he liked what he was doing better.
The fact is that one of these hiring managers would have turned down what Time now calls the 'Man of The Century' because he didn't make that jump to management.
It's too bad (for them) because I am going to eat their lunch with my team of 40+ year old programmers.
Yes, yes, I can see you're very experienced in pushing bits through hardware. Fine. But can you sit down in a room with a bunch of whining user representatives with conflicting and incomplete requirements, a project sponsor with a too-tiny budget, a director who doesn't know the meaning of the word "no", a legacy code base written in the 1980s but bought three years ago because of the glossy brochure, while forty thousand client machines are grinding to a halt because some fool messed with the permissions setting on a database? All this and you want me to stop and babysit an entry-level CS grad while he HAND OPTIMIZES a graphics pipeline because our C++ compiler isn't generating good enough code for me?
Why? For God's sake, man, what makes you think I have the time or inclination to shave 20 cycles out of my already mostly idle processor? Why would I take a perfectly good programmer and have him sweat away a weeks' worth of work for something nobody in my industry even knows how to measure?
I don't want my CS-graduate developers hand optimizing anything. We're in business doing other bean-counting things. Saving 20 cycles is pretty irrelevant to our clients; especially when they have 266 million of them available every second. I know it's damn relevant to many groups including game developers, but for what I work on we are much better off saving billions of cycles by optimizing our flow to reduce time spent waiting for slow, stupid users.
High level languages, and analysis and development processes exist for a reason: less experienced developers get more and better work done. Don't get me completely wrong: I grew up learning both assemblers and HLLs on some pretty obscure CDC and UNIVAC mainframes in the 1970s. I've gone the hand optimizing route. I've gone the hand developing route. I've even still got a roll of red wire-wrap wire in my desk somewhere. I appreciate knowing what I know, and deep inside I agree with you in looking down on those who don't know yet, and probably never will. I still have to go to those CS grad's desks and show them what goes on in the code their compilers emit.
But I've also learned to leave turning code into useful instructions to the compiler vendor. That's their job. My job is to turn our users' activities into useful data. Count the beans, don't drop them. So I don't need the guy who knows all the grungy details of the inner workings of the CPU and compiler. As a matter of fact he'd be damned bored in our shop. I really need him someplace more useful, like working for the compiler vendor. What I need are people who can meet with the users and the analysts and still get code out that serves our business well. If a one-effing-mouse-button development environment makes that happen faster, I only see good come from it.
John
Are you a programmer or developer?
:: carpenter : general contractor
programmer : developer
If you want to be a programmer, accept the unrelenting siege of people who will stay up all hours coding for half your salary. The younger you are, the more likey it is that you will do this.
However, I have never seen young kids or low-cost overseas coder doing things that are required of developers. For example: driving a requirements-gathering process, insisting on design reviews, or battling a project manager for time and resources to QA their software.
In the realm of well-paid developers, we see the other side of the "ageism in IT."
As far as shops that subscribe to the ageist sweatshop philosophy described by the original poster: prepare for an expensive and punishing lesson.
To choose the right container they need to understand algorithmic complexity and the performance guarantees made by each container type (I never said they didn't have to know anything) but they don't need to know how each container is actually implemented. It's the same as needing to know what delivery/ordering guarantees are made when they call a network API, or what durability/consistency guarantees are associated with filesystem calls, without actually knowing how those things are implemented. Interfaces can and should be defined in terms of function, not implementation.
Slashdot - News for Herds. Stuff that Splatters.