Slashdot Mirror
Tech's Dark Secret, It's All About Age
theodp writes "Universities really should tell engineering students what to expect in the long term and how to manage their technical careers. Citing ex-Microsoft CTO David Vaskevitch's belief that younger workers have more energy and are sometimes more creative, Wadwha warns that reports of ageism's death have been greatly exaggerated. While encouraging managers to consider the value of the experience older techies bring, Wadwha also offers some get-real advice to those whose hair is beginning to grey: 1) Move up the ladder into management, architecture, or design; switch to sales or product management; jump ship and become an entrepreneur. 2) If you're going to stay in programming, realize that the deck is stacked against you, so be prepared to earn less as you gain experience. 3) Keep your skills current — to be coding for a living when you're 50, you'll need to be able to out-code the new kids on the block. Wadwha's piece strikes a chord with 50-something Dave Winer, who calls the rampant ageism 'really f***ed up,' adding that, 'It's probably the reason why we keep going around in the same loops over and over, because we chuck our experience, wholesale, every ten years or so.'"
Anyone in the field who hasn't figured this out yet needs to be let go. Programming requires long nights staring blankly at mind-muddling objective languages. Experienced directors/designers have the foresight to be able to properly direct all that youthful energy to the most worthwhile pursuits, rather than just letting them wander aimlessly through some other other geek's code.
When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
What is that? When I was younger I could code more, but I wouldn't say I coded better. Now I take my time and produce efficent, well documented, fully tested code - which functions 1000x better than my 'mass produced' code. Any *good* programmer programs well - not in volume.
Any 50+ year old programmer should be able to keep up with 25yo programmers, knowing how to program isn't just knowing the ins and outs of the hottest language - it is knowing HOW to program so that you can swap languages efficently. (Yes, there is time to learn differences in languages, etc) But anyone worth their salt can jump where needed and go.
Being said, if your first language was cold fusion and it is all you have done for the last 12 years, you may have a difficult time switching to C!
If managers could pay people in their 50's what they people in their 20's, it wouldn't be an issue. As always, the bottom line is the only thing that really matters.
I would like to hear from programmers that have been at it for 10 or more years that aren't 'burned out'
love is just extroverted narcissism
Sounds like you're indulging in a bit of casual ageism yourself! Delightful, innit?
I'm 35. I work with lots of guys who are 15-25 years older than me; some are quite bright, excellent problem solvers, and their experience is tremendously valuable. Others are obnoxious, stale, inflexible, cantankerous pains in the ass. I value the former. I despise the latter - not because they're old, it's because they behave as if their age automatically confers upon them some sort of infallibility in all things technical.
Not surprisingly, the latter group are also the ones - in my experience - who like to knock me (with ~12 years in the field) as "young," "unseasoned," and "still wet behind the ears," normally while I'm disagreeing with their approach and outlining why it's bad, and why a different approach would be better. Because apparently nothing supports their point quite as well as waving away technical limitations with "you're young, you can't possible understand." The former group tends to explain their proposals in such a way that it is immediately obvious why their approach is a technically superior alternative, instead of being condescending pricks to everybody with less experience.
"Old enough to be my parent" is a secondhand appeal to authority - a) you're not my parent; b) if that's the only reason I should be listening to you, you probably aren't as good at your job as you've judged yourself. People old enough to be my parents earn my respect when I see that they are genuine authorities in the subject matter, they don't automatically get it by virtue of the fact that they've been sitting around the office longer than me. Just as I don't expect someone to assume I'm correct simply because "my college training is more recent than yours" - if I'm correct, then it doesn't matter if I'm young or old; if I'm incorrect, the same applies.
The difference between the computing industry and the other industries you mentioned is that computing is hundreds of years younger, and thus changing orders of magnitude faster.
Medicine comes the closest because of continuous research, so doctors are required to stay current with continuing education (they have to do this to maintain certification).
Businesses dump older programmers in favor of newer ones because it's cheaper to hire a out-of-college kid for an entry-level salary than it is to pay a career-programmer his substantially higher salary to learn whatever the newest, hippest, programming style is.
Note: this is a bad thing. It's bad for body of work that is our code-base in every language, and it's bad for the intelligent design of large systems (which requires vast experience). However, it will take a large shift in the rate at which the tools we use in the industry change. If the entire field doesn't change hugely over the course of 2 decades, then someone who has spent the last 2 decades writing code becomes exponentially more valuable.
My other sig is clever.
I leave at 5PM because my experience has taught me how to avoid many of the problem new coders create for themselves. I get twice as much done in half the time compared to when I first started. Looking back at my first experiences as a programmer, I laugh at all the late nights spent working diligently to complete code only to find that I had checked in something inadvertently or forgotten to check something in that broke the build. This in turn wasted many other people time simple because I was too tired to think. The idea that technology has changed tremendously and older coders experience no longer applies is LOL. First the technology has primarily gotten smaller and faster. And coding techniques have improved in some ways but degraded in others. It all still ends up as binary in the end, something many of my younger colleagues don't deem to get which leads to some extremely sloppy techniques. These arguments are mainly bull similar to memes like out sourcing saves money (usually at the expense of time and quality).
There's no future in management, and geeks hate managing people anyway so wtf? I've been asked a few times and no, I won't do it. Thing is, I like writing code. I *enjoy* it. It's why I come to work and what I like to do. I don't *want* to referee the personalities in the office and I surely don't want to be the one who answers for everyone else's fuckups. Not to mention, excess management is usually the first to get cut when job reductions go around. who wants that? I'd rather be a hired hand for some consulting outfit. The benefits suck, and people think your dogsh#t, but if you can get over that it's a good application for experience and the change of scenery on projects is nice too.
boycott slashdot February 10th - 17th check out: altSlashdot.org
It's because hiring managers are afraid to hire people with more experience than they have.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
are concepts that newbies assume can be handled by an API, or automatically garbage-collected...
To be fair, for all practical purposes on many (not all) projects, they not only can be, but probably should be. Your primary focus is on the business or application logic and not on optimization or memory management -- unless it matters, and often it doesn't. For example, I have a sense of how to design a project and write code that supports a high degree of scalability and high availability of services -- but that's been relevant on only a small fraction of the projects I've worked. Wasting time building heavy scalability (for example) into a piece of software that would for certain only ever be used by one person or a handful of people at a time would not be the hallmark of a good programmer.
(Though I agree you can get into trouble if you don't have any sense of when it isn't true that you can let these things slide.)
What I've observed as an I.T. guy who often worked along-side developers is, management often decides a certain technology is the way forward for a given project. At that point, the experienced developers are sometimes left out in the cold, because although they may have, say, 6 years of good experience coding in Java, they didn't spend time on the latest Microsoft technologies. The "new kid on the block", by contrast, may have claimed experience in that area, so to management, he's the "better bet".
Most likely, the REAL problem here is that management doesn't buy into or grasp the idea that the development language used is rather immaterial. If you've got someone with many years of experience coding in a specific language, it'd probably yield the best results to let them continue doing that. Ask them to produce product X or Y with whichever tools they're most versed in using!
Instead though, there's an overall sense that programming languages get "stale" after a while, and a new product needs to be designed with a new language.
I'd say I only have a few personal anecdotal stories to back this belief up, so it could be way off base ... except how much demand is there today for developers with experience in COBOL or Fortran or BASIC, or Pascal, or Forth? I've always worked in a "Support Specialist" or "Network Management" role, but I've observed all these programming languages come and go -- and it seems like such a bad deal for a developer. He/she has to put in so much effort to learn and subsequently master one, only to find it fading into obscurity.
I agree with you that most good programmers don't make good managers or salespeople. However:
The "alternatives" toward which a programmer is supposed to steer according to TFA are plain stupid and slightly offending by assuming that becoming a manager or a Sales ~person~ is a move "UP". How the fuck is your programmer background going to help with those?
A manager or sales person who both is legitimately suited for their job and is technical is a godsend, because they tend to be much less likely to promise their superiors and/or clients the impossible or impractical. They also tend to be better at "selling" the decisions that the development team has made and their tradeoffs.
*nod* That has been my problem with working around untrained 'rockstars'... they can be really bright, but they spend all their time reinventing things that have been around for decades because they did not know the solution already existed off the shelf.
As a middle aged programmer, I always try to keep my knowledge up to date. Yes it comes at the cost of 'free time', but in the end, if I want to have a fun job, I need to do it (and luckily, my significant other understands it and supports me). The other options are: moving into management (which I despise) or be stuck fixing Hadean Cobol code. When I got my degree, I knew only Cobol, Assembler and C. Over the years I added VB, Java and C# to my list along with a bunch of frameworks like .NET, Spring, iBatis, name it. This self teaching has brought me a lot of fun projects in all kinds of languages running on all kinds of systems.
But I can see where this animosity towards older coders comes from: the vast majority of them don't give a damn about new technologies/languages/frameworks. So when the boss decided to use one of those, they won't be able to keep up. In my group of 20 or so coders, maybe 2-3 are continually keeping themselves up to date with recent technologies. Some of the VB coders have hard time grasping class attributes in C#, because they never kept up with object oriented languages. Hell, some of them code in C# as it was VB.
Unfortunately, due to the nature of this domain, I see only one option for me if I want to keep programming: learn or perish. When the next great recession hits, I can at least put multiple language/system skills on my resumé, while some older programmers can't.
Im pretty sure the reasons corporations chuck people is because they can hire a young ones for 50 percent the cost of you old people. They look at small term gains vs. long term sustainable profits. If anything the young ones should be guided directly by you older guys, not slapped in some new formation. Really, its a management issue because they do not recognize other peoples skills but their own as valuable. Management is one of the worst disciplines taught at Universities. It generates a whole bunch of dilettantes that believe the "business degree" hype and think "Well, shit I can get a job making big bucks if I do an MBA and still not work very hard at learning anything difficult." I believe this is why its very important to phase out MBA managers in general and only hire someone like an Industrial Engineer or in this case an actual senior level programmer to do management in any kind of production be it software or physical products.
That brings me to an interesting point, / . is just "the ramblings of socially-inept, technology-literate news-mongers".
The problem at Microsoft is that, once someone has reached a level of experience enabling them to spot flaws in the overall product architecture, they become a burden on management. Questions along the lines of, "Why don't we just fix this crap?" interfere with getting the next release of crap out the door. So its time to move them aside and hire in someone who still thinks Ballmer is God.
It's getting difficult to find such people without having to recruit in the third world.
Have gnu, will travel.
A lot of people seem to think that programmer productivity has something to do with lines of code produced. That misconception gets propagated by uninformed managers, who are basically looking for something that is easy to measure.
In reality, productivity has more to do with achieving required behaviors with a minimum of code-writing. When a fresh-out writes 3000 lines of code, discards or changes 2900 of them, and ends up with a 700 line program that only sort-of works and only remotely resembles the design, after 10 weeks of working 70 hours a week, is that really productive? If an older guy thinks about the problem for two weeks, spends a day or two writing docs, writes a couple pages of code in one morning, tests it that afternoon, tweeks it a little the next morning, spends another day improving comments and updating docs, and has the whole thing finished and solid in 3 weeks, is that really less productive?
Uninformed managers reward the guy who works 80 hours a week and writes lots of bugs. The buggy code needs to be fixed, which then requires heroic amounts of overtime. They reward the overtime, without understanding why it was needed. By contrast, the guy who gets it right the first time, and doesn't need to fix it, doesn't have to work those silly hours. The uninformed managers also do not understand why a program doesn't need to be fixed, and why overtime is not really needed, and so the better programmers are not usually rewarded.
Programming is about function and behavior, not lines of code.
Just for fun, I sometimes run 'uncrustify' on a mess of old code, or change a variable name, before doing a small logic change. My nontechnical director gets a report that counts the lines in each commit.
Ageism isn't a problem for star performers... it is a problem for the "average" people. If you want to do your job for 30 years and never change anything about what it is or what you know... you will be out of luck ...and a job.
It is true in nearly every position, possibly with the exception of some forms of sales or medicine.