Forgot your password?
typodupeerror
Programming

"Logan's Run" Syndrome In Programming 599

Posted by CmdrTaco
from the stay-off-my-lawn dept.
Ian Lamont writes "InfoWorld has an interesting analysis of the reasons behind the relative dearth of programmers over the age of 40. While some people may assume that the recession has provided a handy cover for age discrimination, a closer look suggests that it's the nature of IT itself to push its elderly workers out, in what the article describes as a 'Logan's Run'-like marketplace. A bunch of factors are listed as reasons, including management's misunderstanding of the ways in which developers work: 'Any developer can tell you that not all C or PHP or Java programmers are created equal; some are vastly more productive or creative. However, unless or until there is a way to explicitly demonstrate the productivity differential between a good programmer and a mediocre one, inexperienced or nontechnical hiring managers tend to look at resumes with an eye for youth, under the "more bang for the buck" theory. Cheaper young 'uns will work longer hours and produce more code. The very concept of viewing experience as an asset for raising productivity is a non-factor — much to the detriment of the developer workplace.'"
This discussion has been archived. No new comments can be posted.

"Logan's Run" Syndrome In Programming

Comments Filter:
  • Obivous Answer (Score:5, Insightful)

    by cabjf (710106) on Wednesday February 17, 2010 @01:14PM (#31171678)
    Eventually people do tend to get promoted beyond programming positions.
    • Re: (Score:3, Funny)

      by HeckRuler (1369601)
      Traitors...
      Unless you consider being the archetect to be beyond programming. I assumed you meant transforming perfectly good human beings into pointy haired bosses.
    • Re:Obivous Answer (Score:5, Insightful)

      by starfishsystems (834319) on Wednesday February 17, 2010 @02:21PM (#31173060) Homepage
      "Beyond" programming?

      When I look around, the most limiting factor I see in any enterprise computing environment is the quality of software in use. Multiple teams of people and multiple layers of management are required just to keep it working. Any upgrade plan sends ripples of alarm racing back and forth. And why is there such a status quo of vast inefficiency? Because software is as complex and flawed a contraption as inexperienced programmers can make it.

      It takes an extraordinary person, one having both breadth and depth of experience as well as innate clarity of thought, to design even a moderately large system that's simple and sufficient, modular and extensible. Such people aren't to be found in anyone's junior staff. They don't have the experience. And their talents are lost if they should move into management or some other career.

      It's not a question of "beyond" where programming is concerned. Unlike any other field, the medium in which we work imposes no ceiling on what we can do with it, Gödel incompleteness notwithstanding. There is no "beyond".

      This is such an elementary insight. Since the field itself is not a constraint, what we can achieve is constrained by two factors: our own competence in the field, and time. Given two people of the same natural ability, the one with more experience will be more competent than the one with less experience. That's because, in effect, the experienced one has already put in the time.

      Of course, inexperienced people might not know this.
      • Re:Obivous Answer (Score:5, Insightful)

        by Late Adopter (1492849) on Wednesday February 17, 2010 @03:23PM (#31174146)

        It takes an extraordinary person, one having both breadth and depth of experience as well as innate clarity of thought, to design even a moderately large system that's simple and sufficient, modular and extensible. Such people aren't to be found in anyone's junior staff. They don't have the experience.

        Agreed in entirety! But design and architecture are one of the options I think of when I hear "beyond programming". I don't want the smart people languishing as code monkeys forever, their insights are lost there to all but themselves.

        • Re:Obivous Answer (Score:5, Insightful)

          by starfishsystems (834319) on Wednesday February 17, 2010 @05:01PM (#31175918) Homepage
          Thank you! I think we're in general agreement, but let's explore the implications a bit further.

          Is there any substantive dividing line between design and implementation? If there were one, then people could indeed be left languishing on the wrong side of it. But I don't see one. I think that to impose one is entirely artificial.

          If you're designing and writing specifications without thinking about implementation, you're not giving your best. If you're implementing a spec without regard for principles of design, well, that's just stupid.

          But more than that, it's often the case that the exercise of building something sheds significant light on its design. There's a lot of natural interplay between these two perspectives, in other words. When we discount that interplay we end up with development processes that don't work well at all, because they're not fully informed.

          I need to backtrack a bit here. The problem comes from applying processing concepts to software development that were evolved from the manufacturing industry. In manufacturing, you know what needs to be made; you just have to figure out how to scale up the volume of production. We don't have that situation in software. Far and away the hardest part is expressing what needs to be made, because it's unique each time. The fabrication is trivial.

          Of course there are huge varieties of class libraries and operating system features on hand to provide the nuts and bolts when developing software, but that resource doesn't touch what makes software design a cognitive challenge, and it merely shifts where the cognitive effort of implementation has to be applied. We're still fundamentally conditioned by the two factors I cited before: competence and time.

          To get back to your point, I believe we agree that value is minimized when anyone is asked to function merely as a code monkey. I'm arguing to do away with the distinction. This partitioning of the problem space is pure artifice, a residue of thinking carried over from the Industrial Revolution. I've found that the way to get the most out of people is to let them participate across the broadest range in which they're presently capable. As their capabilities grow, reward them with more involvement and more responsibility. And don't forget to pay them accordingly.

          That's how to address the problem of "languishing" that you rightly identified. But senior developers must not be taken out of the coding process. That's a huge mistake. Yes, they have to divide their attention across many areas, but that's what qualifies them as senior. If you don't expose the junior people to mature ways of thinking, you're throwing away huge opportunities for motivation, mentoring, and just plain knowledge transfer. Worst of all, you end up with a pool of junior people who are disconnected from the rest of the development organization. I see it all the time, and it's toxic.
    • Re:Obivous Answer (Score:5, Insightful)

      by Angst Badger (8636) on Wednesday February 17, 2010 @02:25PM (#31173142)

      Eventually people do tend to get promoted beyond programming positions.

      Sometimes, though it's obviously a minority, or managers would soon outnumber their subordinates. I've turned down lots of management positions. The narcissism of non-technical managers is such that they think everyone wants to be like them, so they are quite sincere in their attempts to reward good programmers with management positions. The problem is that there is next to no overlap in the skillsets, and most often, what you get is a crappy manager in exchange for a good programmer. There are exceptions, but they are definitely the exceptions, not the rule. Some will accept the promotion with the idea that they'll run things better, but then they discover that the cluelessness of the non-technical manager they are replacing wasn't all or even most of the problem: there's the cluelessness of the next level of management behind it.

      As it happens, I actually can do a decent job of managing people. The problem is that I'd rather flip burgers. Consequently, I've stuck to programming and kept my skills updated, but at 39, I'm looking at the reality of a career change in the mid-term future. I'm not terribly worried about it -- I'll have the kid through college in four more years, and after that, I can afford to live on a much, much smaller paycheck.

      Should it be that way? No, of course not. But absent some kind of organized labor movement -- which programmers are notoriously, irrationally averse to -- it's not going to change, as the people making the hiring and firing decisions are getting by just fine with the current system. There is then little choice but to adapt, or at least emigrate.

      • Re:Obivous Answer (Score:5, Interesting)

        by fahrbot-bot (874524) on Wednesday February 17, 2010 @02:56PM (#31173680)

        Consequently, I've stuck to programming and kept my skills updated, but at 39, I'm looking at the reality of a career change in the mid-term future.

        I'm not sure a career change is a future reality, unless that's what you desire. I'm 47 and still highly sought by the various teams where I work. I have a broad background as an application/system programmer *and* system administrator (Unix and Windows) which allows me to develop solutions and, possibly more importantly, debug issues that others with narrower backgrounds simply cannot do. In other words, I get the hard problems - which have to be solved.

      • Re: (Score:3, Interesting)

        by CodeBuster (516420)

        absent some kind of organized labor movement -- which programmers are notoriously, irrationally averse to

        IMHO, this aversion is not as irrational as it might first appear. As you probably know well, many programmers are firm believers in meritocracy; those who can produce elegant solutions to complex problems with clear and concise code are both admired and respected by their peers while those who cannot are not. Contrast this with a common problem in organized labor, rewarding seniority regardless of merit, and you see the principal objection that most programmers have to unionization. If the union rewards me

    • by jayme0227 (1558821) on Wednesday February 17, 2010 @02:58PM (#31173704) Journal

      Everyone knows that all of the programmers over 40 became internet millionaires. That's why they aren't programming anymore. At least I think that's what the brochure said.

    • I like coding well enough, but don't foresee myself still coding in 25 years. I think that's a pretty common feeling among young programmers.
    • Exactly. To quote the article in two places:

      16.7 percent for everyone aged 15 to 24, 8.2 percent for everyone aged 25 to 44, and 6.3 percent for everyone aged 45 and older. So, the older you are, the less likely you are to be unemployed.

      The median weekly salary for workers in the 16-to-24 age bracket is about 41 percent less than what someone aged 25 to 44 makes -- and they're making 6 percent less than the folks in the 55-and-up group.

      At 44, I've finally moved fully into management. The last production l

  • Yes and No (Score:5, Interesting)

    by Concern (819622) * on Wednesday February 17, 2010 @01:14PM (#31171694) Journal

    I have no idea if I'm an outlier, but with a blind preference for intellectual depth, rigor, and creativity, I tend to see what I figured was normal: more experienced candidates often come out ahead. Not always, but often. More experience unsurpisingly equals more age. The best are often bringing decades of experience, MA or PhD level credentials, and the ineffable things that come from having been there and done that in a lot of different trenches. They often cost more (though not all that much more), and they're worth it.

    I know the corporate world at large has this patrician idea about pay related to seniority - whereas I come from the pay-for-value mindset. There is a good observation in the article about older folks making more and therefore being victims of cost cutting. I'm sure this happens as well, but in my world the observation is meaningless. A senior software engineer will get a good salary - more than enough to support an upper middle-class lifestyle (albeit not at the level of an attorney or an anesthesiologist), regardless of their age. If they ask for too much, they will be unemployed; if they tire of unemployment, they bring their compensation demands back in line with their value. I find most people have a very good grasp of the labor market, especially with the advent of widely available salary suvery data.

    I have a couple of friends in their 50's who joke about becoming obsolete. I associate this with actually getting tired of keeping up with an industry that reinvintents itself so often, and therefore, not keeping up. There's a trap there, too: a kind of local maxima where, for a while, being an expert in Cobol or IBM mainframes is not only easier than learning Java, but will pay more and more, as you become more and more rare. Until one day you look for your next job and it just... isn't there.

    Historically IT has suffered from a lack of technical depth at the top. Companies wanted wise old hands with management experience in charge, even if those wise old hands needed an assistant to print their emails every day (true story, multiple companies). As the next generation rises through the ranks, you will have more middle management, SVP, and ultimately COO, CEO, etc types that have real first-hand knowledge of technology. Eventually the corporate world will lose some of its notortious and costly blindness towards talent, and both hiring and strategy will become more objective and less bullshit-driven.

    • Re:Yes and No (Score:5, Interesting)

      by Enderandrew (866215) <enderandrew@g m a il.com> on Wednesday February 17, 2010 @01:16PM (#31171734) Homepage Journal

      Experience is key. The issue is that new applicants coming out school have more experience with .NET, Java and they key technologies that many industries are looking for today. The fact that you have 30 years of COBOL experience doesn't help you if you don't learn new technologies.

      • Re:Yes and No (Score:5, Insightful)

        by 2short (466733) on Wednesday February 17, 2010 @01:29PM (#31172016)

        True, but if it's for a job doing .NET programming (for example) a lot of people doing hiring will take the guy with 1 year of .NET experience and nothing else over the guy with 30 years experience in 5 different languages and no .NET. All else being equal, the latter guy will probably be more valuable.
        • Re:Yes and No (Score:5, Insightful)

          by Minwee (522556) <dcr@neverwhen.org> on Wednesday February 17, 2010 @02:04PM (#31172712) Homepage

          On the other hand, the guy with thirty years experience probably expects to leave the office at the end of the day and not work overnight and on weekends. The guy with one year of .NET experience may even believe tales like "We're going to have to put in a few extra hours to finish this project, but we'll make it up to you after we ship", "That's the way everybody in the industry does this" and "I'd hate to see you have to leave the company because you didn't want to be a team player".

          While the more experienced developer is obviously a valuable addition to a well run team, Junior is much easier for a dysfunctional team to exploit, throw away and then replace next year.

          • Re:Yes and No (Score:4, Insightful)

            by greenbird (859670) * on Wednesday February 17, 2010 @05:58PM (#31176798)

            On the other hand, the guy with thirty years experience probably expects to leave the office at the end of the day and not work overnight and on weekends.

            The more experienced programmer you won't have to work nights and weekends to complete the project. 30 years experience provides the foresight to avoid the development black holes that create the situations where you have to work nights and weekends to complete the project.

          • Re:Yes and No (Score:4, Interesting)

            by SimonInOz (579741) on Wednesday February 17, 2010 @06:34PM (#31177306)

            Ah, what a great thread. And as I turn 55 tomorrow, I guess it's pertinent.

            I currently "manage" a team of young programmers (nearly all from India, based in Australia). They are happy to slog away, coding until they are blue in the face.
            Lines of code - they'll give you lines of code.

            But do they think much - er, no, not as far as I can see.

            I am rubbish at managing. My main function is staying out of the way, and going to meetings. Oh, and doing estimates (guess at what you think the work might take. Round up to days, multiply it by about ten, double it to allow for testing ... then think if there might be any other problems and add a bit. This is a bank, we have a FIXED release schedule. So our aspirations are way, way low. No rewards for wonderful work, only punishment for not delivering on time ... we aim low, so, so low).

            But I still reckon I could out program pretty much my whole team. (Yes, arrogance is a requirement for a decent programmer). And I would so, so much rather do that. So I write code to entertain myself, spending about 10% of my time on management.

            I weep when I see the miserable approach they take - why write a general solution when you could write more code? Why use a library when you could just - write more code. And so on.

            And get off my lawn ...

        • Re:Yes and No (Score:5, Interesting)

          by DerekLyons (302214) <fairwater@gmail. c o m> on Wednesday February 17, 2010 @02:53PM (#31173630) Homepage

          True, but if it's for a job doing .NET programming (for example) a lot of people doing hiring will take the guy with 1 year of .NET experience and nothing else over the guy with 30 years experience in 5 different languages and no .NET. All else being equal, the latter guy will probably be more valuable.

          If I'm hiring someone to do .NET programming, I see no a priori reason to assume that the guy without any .NET experience would be a better hire than a with .NET experience.
           
          I'm reminded of the home improvement show I saw a few weeks back. A highly experienced contractor was brought in to do a remodel, and on the surface did an excellent job. But after a few months problems began to surface that he couldn't (or wouldn't) fix. The guy brought in to fix the problems traced many of them to the original contractor using new materials but old techniques that weren't suitable to the new materials and didn't take into account current building practices.
           
          All else being equal, the original contractor with decades of experience should have been a good choice, but in reality he was an iceman - frozen in time and irrelevant to the modern era.

        • Re: (Score:3, Interesting)

          by rachit (163465)

          I've worked at a couple startups, and the unfortunate truth is when we hire someone, we expect them to be productive by the end of the first week.

          A less experienced guy with the right skills will win out over the more experienced guys without those skills, especially if you factor in the cost and possible "ego" issues. At a startup everyone has to do the dirty work. Its sometimes more difficult to get the experienced folk to wear the build engineer hat for the day, or handle a support escalation.

      • Re:Yes and No (Score:5, Insightful)

        by LWATCDR (28044) on Wednesday February 17, 2010 @01:35PM (#31172122) Homepage Journal

        "The fact that you have 30 years of COBOL experience doesn't help you if you don't learn new technologies."
        learning a new language is easy. Learning to program is hard.
        c, java, c#, php, perl, are all very much alike. Once you know one learning the rest are easy.
        In your typical application program so much code is now offloaded to the libraries that once you leave school you are unlikly to have to write a HASH or a sort every again.
        What experence teachs you is when you need to use a hash vs a btree.

        • Re: (Score:3, Insightful)

          learning a new language is easy. Learning to program is hard.

          QFT

          IANAP but have written code as a hobbyist. I'll spend hours writing and rewriting something only mildly complex because, while I understand the languages and syntax well enough, I use trial and error to find the right methods. Starting with only a vague idea of how I want something to work doesn't help, either. Good programmers know the right methods already, and learning how those methods are applied in any particular language is trivial.

        • Re:Yes and No (Score:5, Interesting)

          by alan_dershowitz (586542) on Wednesday February 17, 2010 @01:51PM (#31172430)

          Learning how to not leverage 30 years of COBOL experience by programming in COBOL in every other language you use is hard.

          I maintain C code written by a COBOL programmer. You can tell.

        • Re:Yes and No (Score:5, Insightful)

          by Alinabi (464689) on Wednesday February 17, 2010 @02:15PM (#31172942)

          What experence teachs you is when you need to use a hash vs a btree.

          Actually, school teaches you that. If it didn't, you were not paying attention in class.

          • Re:Yes and No (Score:5, Insightful)

            by khallow (566160) on Wednesday February 17, 2010 @02:29PM (#31173200)

            Actually, school teaches you that. If it didn't, you were not paying attention in class.

            You make a common mistake. Teaching is not the same thing as learning. Learning is what sticks and it includes knowledge that didn't come from the "teaching" end.

        • by elnyka (803306)

          "The fact that you have 30 years of COBOL experience doesn't help you if you don't learn new technologies." learning a new language is easy. Learning to program is hard. c, java, c#, php, perl, are all very much alike.

          Barring the curly braces and common control structures, no, they are not. Not even freaking close to be alike by any stretch of the imagination. C very much alike to Java, C#, PHP? Perl? I mean, C???? Of these bunch, only Java and C# are mildly similar, and only superficially.

          Once you know one learning the rest are easy.

          The problem with that thinking is that you only think about trivial code examples of any of those languages. When you start using them for non-trivial tasks, you find that there are obscure semantic idiosyncrasies that either make or b

      • Re:Yes and No (Score:5, Insightful)

        by Opportunist (166417) on Wednesday February 17, 2010 @01:51PM (#31172436)

        Just wait 'til Y3K rolls over and we old COBOL proggers will be sought after again!

        Ok, aside of lame jokes, it's a misconception that "you have to know $language_FOTM to be useful". You have to know how to program to be useful in the long run. Of course, all those fast breeder COBOL programmers that were cranked out 30+ years ago when COBOL was the be-all, end-all language of the trade will not have any future. Neither will the same kind of fast breeder .net codemonkeys have any. They will be used now 'til nobody cares about .net anymore, then they will be tossed and retrained to ... car salesmen or whatever needs more people then.

        What's left is programmers who do not learn a programming language but to program. It does not matter if you write C, C++, Java or C# code. It's basically the same concept. I could see that there is a genuine difference between an imperative and a descriptive language, but ALL the languages mentioned above ARE imperative. If it does matter to you that you're supposed to use a different one, you have no right to call yourself a programmer in my eyes. Because the algorithm does not change. The words you write, the symbols you use and maybe a few tidbits to take care of do. But the foundation stays the same.

        Programming is not knowing an API by heart. That's something help files are here for. Programming is not knowing what library contains what functions. Check your manual for reference. Programming is knowing how to translate a problem into code. What language is used to do that translation is not important.

        • Re: (Score:3, Interesting)

          by HappyEngineer (888000)

          Programming is not knowing an API by heart. That's something help files are here for.

          That is profoundly untrue. It may be true that you can learn the basics of new APIs quickly, but most APIs have gotchas. Gotchas wouldn't be gotchas if they were easy to avoid. You learn them by using the API and then debugging the bugs and then remembering those gotchas the next time you use the API.

          In Java, when you call new GregorianCalendar(2010,1,1) and end up with a date in February you'll learn a gotcha. When you

      • Re:Yes and No (Score:5, Insightful)

        by mollog (841386) on Wednesday February 17, 2010 @01:52PM (#31172460)
        Experience is key. The issue is that new applicants coming out school have more experience with .NET, Java and they key technologies that many industries are looking for today.

        Arrant crap. The best programmer I know is in his 60's and got his start on IBM mainframes. He's the go-to guy when you're writing a new OS for your next imbedded application. As others have already said, once you've been through a few languages, JCL, Cobol, Fortran, C, C++, Java, TCL, the next language doesn't even register as a 'new' language.

        The reluctance of younger managers to hire older programmers has less to do with skill and ability, and more to do with psychological factors such as an older programmer's ability to instantly see the folly of what a younger manager wants to try. Been there, tried that, fuggetaboutit.
        • Re: (Score:3, Insightful)

          by Maxo-Texas (864189)

          Older programmers will typically not repeat the same naive mistakes again.

          OTH

          A large percentage of older programmers are unable to learn a new programming model. For example: Object Oriented coding. There are some who just do not get it and will write procedural code in object oriented languages.

          by and large, programming as a field in general has such low status and poor conditions that I can't recommend it to anyone any more. Go into programming if you

          a) want to likely suffer terrible age discrimination

          • by SimonInOz (579741) on Wednesday February 17, 2010 @06:45PM (#31177492)

            Your sig is right - oh, so bitter.

            Damn, where do I start?

            Age discrimination and a truncated career - 55, still in IT. Can't be that bad. But there's some truth in it.
            Learning new ways of doing the same work - new tools, similar problems. Beats using the same tools for the same problems (like, say, a plumber).
            Substandard pay - nope.
            Compete with 3rd world labour - quality will out. Be good at what you do. Aren't you?
            Work nights ... try delivering on time. Aren't you good at what you do? Hang on, didn't I just say that?
            5am - see above. Or try being a plumber.
            Holidays ... what is it with you and not getting things done on time?
            Vacation ... oh, you are American. Anyway, see above.
            No respect - respect must be earned, whatever you do, be it a plumber, a janitor, a judge, a programmer. Try being nice to people.
            Implementing stupid solutions - can be a problem. Earn some respect, become involved in the process.

            Girlfriends/spouses - you really do have problems, don't you? Try earning and giving some respect, change your t-shirt occasionally, maybe to one with sarcastic, bitter remarks on it. Maybe the world will love you more.

            If you don't like this field, please leave. If you do not enjoy the challenge of one of the fastest paced, most technical areas around, just quit. Go work in a shop (mindless tedium), be a plumber (on call 24 hours, fixing broken toilets), a lawyer (everyone hates you), a factory worker (you hate yourself), a garbage collect (damn they die a lot. And girlfriends?)

            I think I'll stick with it.

    • That's not what your hand crystal says; report to carrousel.

    • by Anonymous Coward on Wednesday February 17, 2010 @01:34PM (#31172106)

      I'm 59, and have been programming professionally since I was 20. The two best things for my employment are:
            1) Young, inexperienced programmers.
            2) "Experienced" Indian programmers.

      Why is that? Because they both fuck up constantly, and thus give me lots to fix.

      Young and inexperienced programmers are a delight to work with. It's great to see them come into a project all cocksure, only to be crushed by the demands of the real world. They'll spent countless hours putting together shitty software, which will always fail. Then management calls me in, and I fix their code. Mostly this means rewriting it all from scratch. Regardless, I make about four times what they do. Then again, I deliver working code.

      "Experienced" Indian programmers and "software architects" are the next best thing. They're like the young and inexperienced programmers, but their fuckups are much, much bigger. That means the customer's desperation is much greater, and I can make more money. What's best about these guys is that they often haven't produced even a line of code. They just spew out UML diagram after UML diagram. I look at the diagrams, talk to the users, and it becomes obvious what should be done. I sit down, implement the software, satisfy the customer, and collect my money.

      • Re: (Score:3, Informative)

        by Homr Zodyssey (905161)

        It's like you're describing my life -- only 25 years in the future. I'm 34, and seeing the same thing.

        The part that I'm finding frustrating is the boss that says, "I really think will be a valuable asset, they just need a little mentoring." So, I spend my day mentoring that person instead of getting my work done. "Mentoring" means first giving them a hint about how to do something. Then 30 minutes later telling them exactly how to do it. Then an hour later, sitting at their PC and typing the code in f

      • by fahrbot-bot (874524) on Wednesday February 17, 2010 @03:10PM (#31173918)

        Young and inexperienced programmers are a delight to work with. It's great to see them come into a project all cocksure, only to be crushed by the demands of the real world.

        Actual example. We had a fresh-from-college junior programmer and my manager asked if a particular (Perl) assignment would be appropriate for him. I wasn't sure, so offered to do the work myself in parallel with the new guy and mentor him on it.

        It took the new guy two weeks, with help from me - answering questions, giving advise and hints. When done he wondered when we would be promoted to senior programmer. I replied most likely when he didn't another senior programmer to help him so much and when he could be more productive.

        He asked how long it took me to do the parallel assignment. I replied, truthfully, "two hours" - which is why I had the answers to all his questions so readily.

  • When my last boss was 20 years younger than me, I changed professions... I'm not that old...
  • by garg0yle (208225) on Wednesday February 17, 2010 @01:16PM (#31171744) Journal

    Not only are younger coders generally cheaper, they also generally are more into the "new technologies" -- as a programmer gets older, it becomes almost a second job to keep up with the new technology as it comes out, and at some point I suspect that many just decide it's easier to get off the carousel and go find something else to do.

    As an example, if you've been coding in COBOL for 20 years, Java can be an awkward language to learn. However, many new grads in the last 10 years learned Java as their first language. As such, even though the senior coder probably would perform better in the long run (due to more experience with designing efficient algorithms and more knowledge of internal business processes), management would likely hire a couple of recent grads rather than pay to have our COBOL programmer trained in Java.

    • Re: (Score:3, Informative)

      by jythie (914043)
      Besides new technologies, one also needs to keep up with the current flavor of 'one true way' programming. Multi-paridigm programmers are increasingly being seen as warped or 'in need of training' since they can *gasp* see value in something other then the current snapshot of how OOP is done. Experience and perspective become detriments unless one knows which current fad to focus on and which ones you are supposed to say have no value.
  • Career path (Score:4, Insightful)

    by jdgeorge (18767) on Wednesday February 17, 2010 @01:20PM (#31171814)

    As others have already noted, the career path of technical people often moves beyond "just programming" at some point. By the time folks have reached 40, they've (hopefully) got a good sense of how to make good decisions about what products and features to develop and how, not just how to write efficient code.

    While some of the technical leaders in my area do write some code, the bulk of what they are needed for is making decisions about what we ought to be doing, and providing guidance for the younger programmers or ensuring quality communication with other lead developers.

  • ageism (Score:4, Interesting)

    by spineboy (22918) on Wednesday February 17, 2010 @01:20PM (#31171820) Journal

    And it's present in many industries/areas. No one wants anyone over 40 for rock, screen writers are ignored if they're over 40, since "They don't know what it's like to be a kid."
    The list goes on.

    In programming, I think it's foolish. People are getting caught up on the techniques, and not the theories. Unfortunately, techniques become quickly dated, and irrelevant, while theory always will be useful

  • by royallthefourth (1564389) <royallthefourth@gmail.com> on Wednesday February 17, 2010 @01:21PM (#31171842)

    The summary says that it's not merely age discrimination, then goes on to say that they hire younger workers because they are cheaper, without bothering to account for experience.
    That is age discrimination.

    What a horrible, stupid summary.

    • I was once "fired" because I was the "old hand" in a department that had a sudden influx of developers over ten years junior to me. Yes, I sued and won based on age discrimination. From my standpoint, managers hire younger workers because they'll work longer hours for less pay, and are less likely to have the "encumbrace" of families to keep them from working OT, or that call them away because someone's home sick, or has to be run to an appointment. Also, the boss usually prefers people his own age who'l
      • by tsm_sf (545316) on Wednesday February 17, 2010 @01:37PM (#31172156) Journal
        I was once young enough to work 16 hour days. Now I know better. That is the entirety of the "problem".
        • by mcgrew (92797) * on Wednesday February 17, 2010 @03:13PM (#31173980) Homepage Journal

          I was once young enough to work 16 hour days. Now I know better. That is the entirety of the "problem".

          My friend Amy, whose dad would be a year younger than me had he lived, is amazed by my ability to come home from work, drink with her until the wee hours, and get up and go to work the next day. Perhaps that's because I was never stupid enough to work a 16 hour day -- I don't live to work, I work to live. I've been like that since I started working at age 16. I'm 57 now and look ten years younger than friends who are ten years younger than me.

          Hell, I once passed up a promotion just to not have to work overtime. Money is just a tool, and one should never let his tools get in the way of what you obtained the tools for in the first place.

    • The summary says that it's not merely age discrimination, then goes on to say that they hire younger workers because they are cheaper, without bothering to account for experience. That is age discrimination.

      That is not age discrimination. Younger workers are hired because they are cheaper, not because they are younger. If two people cost the same and the older of the two was better-qualified, but the younger was hired anyway, that is age discrimination. I can see why you would be confused, since younger people tend to also cost less.

      Unfortunately, programming experience doesn't linearly scale with code quality. Eventually, the gain in code quality tapers off, and the more-experienced higher-salaried employee

  • jaded (Score:5, Insightful)

    by convolvatron (176505) on Wednesday February 17, 2010 @01:22PM (#31171880)

    the problem with having older programmers like myself is that they are fully tired of being jerked around
    by incompetent management. if you've worked in 20 shops, and run a few yourself, you're alot less
    likely to happily pull an all nighter to try to get the release out the door. you understand
    that this all could have been taken care of months ago, and you went to some pains to point that
    out then.

    the other kind of older programmer has just given up. they know better, but they understand
    that bitching isn't going to solve anything and they need the health insurance. they look alot
    less capable then they are because they just agree with everything and try to get out the door
    by 5.

    younger programmers dont know any better, they will believe whatever you say

    • There is a third kind of older programmer: disillusioned with crappy management but still wanting to do development, they strike out on their own. They either go freelance as some sort of contractor/consultant, or found their own company and bring in other people to do the business side of things while they stay technical.

    • by coolmoose25 (1057210) on Wednesday February 17, 2010 @01:50PM (#31172412)
      The phases of programming (and lots of other things) are:

      - Disgruntled
      - Jaded
      - Bitter
      - Postal
      - Indifferent

      The Systems Development Life Cycle can be thusly described:

      - Wild Enthusiam
      - Beffudlement
      - The Disaster
      - The Search for the Guilty
      - The Punishment of the Innocent
      - The Promotion of the Uninvolved

      (yes - 45 year old programmer who is now a pointy haired bossman)
  • No really (Score:2, Interesting)

    by Anonymous Coward

    The problem is not about Age: is about Money. You having X years of experience you want X amount of money. Managers think that they can replace that with somebody cheaper (Why you can get somebody that have experience and can produce good code better than 3 when we can get 10 from India making 15,000 a year and no benefits)

    Sorry Boys and Girls we ALL are in the same boat.

    P.S In the defense of Indian programmers they are in the same bad position (I think even worst than ours). Having X amount of years of exp

  • Kids Today (Score:5, Funny)

    by handy_vandal (606174) on Wednesday February 17, 2010 @01:26PM (#31171952) Homepage Journal

    Kids today have it easy -- context sensitive development environments, online documentation, etc. etc.

    Why, when I was your age, we had to chisel bluestone megaliths using only hand tools, and then haul those four-ton stones into a circular pattern, just to calculate date() ...!

  • Experience (Score:5, Insightful)

    by copponex (13876) on Wednesday February 17, 2010 @01:26PM (#31171954) Homepage

    Across every industry I've been involved in, a good piece of advice from an old business mentor has held true:

    When you pay an expert $100 an hour, you're not paying them for the hour. You're paying them for the years of experience they have plus an hour of their time.

    This also dovetailed well with what a mechanic told me when I was trying to lowball him: "When you pay peanuts, all you get is monkey business."

  • by realsilly (186931) on Wednesday February 17, 2010 @01:33PM (#31172100)

    Is the younger generation of programmers really that arrogant to think that older programmers don't know and learn new languages and coding trends? it is my experience that the best coders out there are those over 40. Not only are they on top of technologies that are current, but they understand why those technologies came to be and what they helped to improve. Many of them learned on the job, in a budding industry.

    Just a few days ago there was a post right here on Slashdot asking how easy it was to cheat in CS. Based on the forum discussions, a significant number of students today get programming degrees and can't produce a lick of decent code.

    This is NOT to say that there is not an abundance of exceptional young talent, there is, and they deserve good work and decent pay, but this is in defense of those who helped pave the way.

  • Age Test (Score:5, Funny)

    by Sponge Bath (413667) on Wednesday February 17, 2010 @01:34PM (#31172116)

    If you read this article and are thinking about your career, then you are young. If you are thinking about a naked Jennifer Agutter, then you are old.

  • by Lazy Jones (8403) on Wednesday February 17, 2010 @01:37PM (#31172160) Homepage Journal
    ... you should have finished the Perl script that does your job / earns your living. Unless you promoted yourself to management, in which case I pity you, fool.
  • by SmallFurryCreature (593017) on Wednesday February 17, 2010 @01:52PM (#31172442) Journal

    Approaching the age of 40 at break neck speeds, I am going to find out how true it is that there are no old coders.

    But frankly, I don't think it is going to be a huge issue unless 40 turns out to be a really magical number. I have had no problems before. Granted, junior positions are no longer open to me, but then, why would I want to?

    I have found that at least in Holland there is a real shortage of good web developers, people who can not just put up a website but maintain it and worse, debug somebody elses mess. There are tons of LAMP developers it seems, and yet companies can't find them. But you got to be able to deliver, how many of the programmers who complain they can't find a job really just aren't any good?

    In fact in an interview Backbase, an small but international developer said in "De Pers" that they were so desperate for experienced developers they had put a freeze on hiring juniors because they did not have the people to train/lead them.

    Yes, some companies might prefer to hire someone young, but these tend to be the grindhouses of the industry, were they churn out project after project with no quality for a low low price. You all know them, the companies that do government IT. If you IT department still insists you run IE6, then you got one of them.

    But there are countless more companies that do try to work for their money were experience and maturity are needed to keep the enthusiasm of the younger developers in line. There has to be someone who can actually debug a third party app if the shit hits the fan and do it without constant hand holding. There is in development and certainly web-development a lot of grunt work that is really a waste to put a senior on, but I have seen what junior's today are 'capable' of. Or rather not capable. It is the parts of a project that go beyond the "teach yourself X in 24 hours" books or even school. It is the years of experience encountering all kind of problems that turn a junior into a senior.

    A smart company therefor has both kinds, the juniors for the grind work and to bring in new ideas, the seniors to keep it all running smoothly.

    And if your company ain't smart enough for that? Move on as fast as possible.

    BUT I just re-read the summary AND the article and there is a problem. The article is about IT-workers while the summary is about programmers. I have started to notice that there is a difference to the point that developers really aren't part of IT at all. I always thought we were, but others disagree.

    So, is the article about how their are no old help-desk jockey's? And could this be because there is a job for senior dev's but not for senior printer unjammers? Just what is IT? A 60+ senior developer is a respectable position, if you are 60+ and still have to install new PC's you screwed up and a kid can do your job cheaper.

    In conclusion, I am not all that worried. Any company not willing to hire a 40+ developer with over 2 decades experience on countless successful projects, I wouldn't want to work for anyway.

  • by oudzeeman (684485) on Wednesday February 17, 2010 @02:52PM (#31173608)

    We just filled a senior level programmer position with someone in their 50s. This person had a great resume, and did an awesome job in their interview - blew pretty much everyone else we looked at away. I'd say he's easily 1000X better than the last young intern we had (now a grad student in CS). I'd say most of the programmers here are in their late 30s to mid 40s. A few are older (50ish). I'm a young one here, a "senior" software engineer by title at the age of 30.

    We're actually considering going after some young blood and spending the effort to mentor them because we have such a hard time recruiting older developers.

  • by joeyblades (785896) on Wednesday February 17, 2010 @02:53PM (#31173626)

    I have observed the opposite. The young 'uns want to go home early so they can party and come in late 'cause they partied last night... And at home, when I'm punching in some extra hours, I only ever see old farts still on-line.

  • by ErichTheRed (39327) on Wednesday February 17, 2010 @03:24PM (#31174182)

    (Disclaimer: I'm a systems guy, not a programmer, but a very similar truth holds for us as well when it comes to age discrimination.)

    I'm only 35, and I'm starting to see this creeping in on me also. Here's a couple of random observations I've actually (not anecdotally) experienced:

    • Companies absolutely believe the stereotype that older workers are less productive. Usually, this is because management gets promoted out of the tech ranks, where they were used to younger workers. I've heard more than one boss say something like "Oh, so-and-so's kid is sick AGAIN, what a waste of time." The deadly spiral of "willing to work longer hours, no committments, and they can be paid less" does not help.
    • A corrolary to the above...younger tech workers tend to have much less of an "out of work" life. This is why you don't see too many older people working at video game production houses...you just can't hold a marriage together on nonstop 90-hour weeks. If you're single, and have nothing but a one bedroom apartment and XBox to come home to, you're going to complain less about constant overtime and that pesky pager duty us systems guys deal with.
    • After being filtered through 2 line managers, and who-knows-how-many project managers, IT executive leadership just doesn't see the impact of less-experienced people working on projects. Messes are cleaned up at lower levels, usually by spending a buttload of money on consultants, and only show up at the senior level as "minor overages". Had the job been done right, the higher salary paid to more experienced people would far outweigh paying experts $xxx/hr to unravel some mess put together by someone who just learned Java.
    • Even worse, people at the C-level believe that all IT people are whiny nerds who can be pushed around with very little pushback. This leads to the belief that nothing they do will be questioned.

    I only see a couple solutions. A concerted effort could be made to make managerment aware of the actual cost of a project vs. the salary differential. I doubt that will work. You can also become one of those consultants, and get paid loads of money to clean up messes. However, that's not for everyone...it requires tons of hard work, business savvy and is not at all stable. Try raising a family with no health insurance and a non-guaranteed income stream, especially in a high-cost-of-living area.

    I admit that I'm pretty lucky. I've managed to land at companies that don't seem to mind paying a little extra for someone who really knows their stuff. The price of admission for jobs like that is the willingness to invest in yourself constantly. Taking classes or buying software/hardware/books for training, even on your own time, is the best way to keep current. That way, companies get the best of both worlds...someone who knows the latest tech, and knows enough not to implement something half-baked because they want their weekends free. :-) Unfortunately, that stereotype of the COBOL guy sitting in the corner has a little bit of truth to it, and it means we end up gettting painted with the same brush.

    One other choice would require a much different mindset than there is now...accept a lower salary and make up the difference by saving and investing carefully. I've been doing this anyway, because I know there will come a time where companies stop paying for IT talent and I'm going to be forced to take a huge paycut. Everyone I know, young or old, spends money like their income is never going to decrease. Live within your means so you can last through the bad times that are coming with the next wave of globalization.

Uncompensated overtime? Just Say No.

Working...