Discussions

News: Five Myths About Older Developers

  1. Five Myths About Older Developers (82 messages)

    Dave, a Java developer, writes: I recently celebrated my 40th birthday. A friend joked, "Hey, guess that means you're too old to program anymore!" I laughed on the outside, but it gave me pause. COBOL guys faced this problem years ago as Java guys were ascending the ranks, and we laughed about legacy code and their inflexibility with new technology. Dave dispels 5 pervasive, negative myths about older software developers. He continues:
    There are a number of myths about older software developers that continue to be perpetuated in IT and software development that somehow put older, experienced workers at a disadvantage in our field. But they're largely crap and considering the degree trends, ignoring everyone 40 and over because we're too old seems plain foolish. Let's debunk these myths one-by-one.
    The myths in question are:
    • Older software developers are more expensive than younger ones, making younger developers more desirable.
    • Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge.
    • Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours) because of family commitments and other attachments that younger workers don't have.
    • Older software developers are less mentally agile than younger ones.
    • Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones. Younger developers are more enthusiastic than older ones.
    Whether you're approaching the 40-year old mark, or have already passed it, sooner or later you'll get a chance to test whether these myths are true. What do you think?

    Threaded Messages (82)

  2. I don't think it's a matter of age. I know a number of young guys with all the listed flaws ascribed to oldies. There is a paper about developers quality at ZeroC.com written by Michi Henning (who would ever hire Michi, naaa, too old, too expensive). It could be a really good reading. Personally, I am 50 and a I can still do the same task of an average developer (you know, those who implements tons of DAO when the persistence layer is jdo/jpa, those who write tons of ejb with managed transaction and create inconsistent database, those who design distributed systems with bean-like objects, preferably with SOAP) 4/5 times faster and with a quality even higher. The real problems is that there is less interest in having the things done right. Commercial guys are particularly skilled in the management of angry customers rather than of well-trained and professional developers. But I don't mind too much any more. I getting old. Guido
  3. I am 50+ and I DON'T fit any of those myths based on stereotyping. It's mostly a state of mind, if you are passionate about software. Most employers value my worth and care little about my age. I stay away from employers that I feel may be sensitive about my age. Pranab
  4. I am 50+ and I DON'T fit any of those myths based on stereotyping. It's mostly a state of mind, if you are passionate about software.

    Most employers value my worth and care little about my age. I stay away from employers that I feel may be sensitive about my age.

    Pranab
    I second that statement, im 34..... Only think i could agree with is that younger programmers are more willing to work around the clock that others..but as a PM once told me when i was younger(23) while working 15 hour days like it was cool.... he said "Work smarter not harder"..that lesson can only be learned from experience. =) Happy coding :)
  5. Long Hours[ Go to top ]

    Only think i could agree with is that younger programmers are more willing to work around the clock that others..but as a PM once told me when i was younger(23) while working 15 hour days like it was cool.... he said "Work smarter not harder"..that lesson can only be learned from experience. =)

    Happy coding :)
    With respect to putting in longer hours, it's not that us older guys aren't willing; it's that we've been around long enough to realize it doesn't buy you a damn thing. When I was younger, yes, I put in those long hours to meet unrealistic deadlines that were set by salesmen who didn't bother to consult with IT before making commitments to customers. But, after a while, you wise up and realize, "Hey! I'm putting in the long hours to make this project deadline so this salesman can get the big commission for the sale, while I get nothing extra because I'm salaried." Or, you see yourself putting in 60-70 hours per week, but the guy who puts in 40 hours per week gets the same annual pay raise percentage as you do. Those types of experiences, across multiple corporations, teach you that mediocrity gets rewarded as much, and often times more richly, than those who consistently get an "outstanding" on their reviews. If it takes someone more than 5 years in this industry to figure that out, then they're not too sharp. Now, I use my personal time to increase my skill sets - not to make up for someone else's lousy planning skills. R. Grimes
  6. Re: Long Hours[ Go to top ]

    Only think i could agree with is that younger programmers are more willing to work around the clock that others..but as a PM once told me when i was younger(23) while working 15 hour days like it was cool.... he said "Work smarter not harder"..that lesson can only be learned from experience. =)

    Happy coding :)


    With respect to putting in longer hours, it's not that us older guys aren't willing; it's that we've been around long enough to realize it doesn't buy you a damn thing.

    When I was younger, yes, I put in those long hours to meet unrealistic deadlines that were set by salesmen who didn't bother to consult with IT before making commitments to customers. But, after a while, you wise up and realize, "Hey! I'm putting in the long hours to make this project deadline so this salesman can get the big commission for the sale, while I get nothing extra because I'm salaried." Or, you see yourself putting in 60-70 hours per week, but the guy who puts in 40 hours per week gets the same annual pay raise percentage as you do.

    Those types of experiences, across multiple corporations, teach you that mediocrity gets rewarded as much, and often times more richly, than those who consistently get an "outstanding" on their reviews.

    If it takes someone more than 5 years in this industry to figure that out, then they're not too sharp.

    Now, I use my personal time to increase my skill sets - not to make up for someone else's lousy planning skills.

    R. Grimes
    Well said. And add to this living through a few recessions. There's nothing like seeing people who gave their all, cut loose. Companies rarely repay such loyalty. Or at least the payment is not what's expected.
  7. says who[ Go to top ]

    I don't know which side of the discussion this comes down on, but according to Wikipedia, COBOL is 51 years old and Grace Hopper was 50 when she conceptualized and developed it.
  8. One of the most impressive programmers I ever worked with was a wizard, with long white hair and IBM core memory boards for office art: not older, rather old. Brilliant. The 2nd place would probably go to another friend (who at the time we worked together was late 30s). Turned me on to Smalltalk and Lisp and generally challenged my conceptual thinking quite a bit. Scary smart. I have certainly recognized the signs of a budding future (older) software wiz in a few of my younger colleagues as well, but nothing to even approach the level of the master level programmer (such as the two gents above). And in spirit of the sweeping generalization per this thread, I would put forward that (minus perhaps the time and politics management considerations) the programmer is the person. He is quality when young, and quality when he is old.
  9. Development is probably one of the most complicated tasks you can do, in this context experience is a top value, complexity management is by far more complex than learning any API. Rejecting old guys drives to chronic mediocrity and chronic amateurism, is this the kind of quality are customers demanding? These days we see new object oriented databases like Neo4Java, some people see them like the last revolution when this technology is here many years ago, in fact Robert Greene of Versant was explaining what an OODBMS database is, Versant a product with more than 10 years old based on a technology (OODBMS) 15 years or more aged and very very important some time ago... crazy. It has a name: experience destruction.
  10. Ah shucks .... you're showing my age ;-) Such thoughts should be responded to in line with the years of critical thinking which resulted in common expressions such as .... "throwing the baby out with the bath water" My .02 ....These are individual things. I do know some young developers who have an apparent wealth of knowledge and understand well how to handle complexity in software systems. I also know some older chaps doing procedural programming with object oriented languages..... AND the other way round. Generally, it's the knowledge and behavior which cannot be hidden and this is what moves people into one project and/or team position -vs- another. In this world, it takes all kinds. Cheers, -Robert Use the right tool for the job! Versant Corp
  11. I think there is truth to this but not for the reasons you might expect. I also believe that you need older developers to have an effective team and they the extra that you (quite rightly) pay for them is more than worth it. The reality is that a lot of people leave the field because it mostly sucks to work in it. A lot of people who are smart and driven will just say "F*^5 that noise" and change careers to something where their hard work will be rewarded. This isn't across the board. A lot of people just love to solve development problems and that's the pool you want to get your graybeards from. Our industry desperately needs to revise the way we think about older developers and older developers need to think differently about their careers. We need to take our experience and mentor younger developers. Management needs to realize this is the only way forward and make it clear to their experienced technical staff. I haven't seen a lot of this in my career. I had to learn most everything on my own.
  12. Well, I'm not quite 40 yet but I think there's some truth around this statement: --Younger developers are more enthusiastic than older ones. To be a cutting-edge developer, its a constant chore of doing what you do in your day job while learning the new stuff at night, weekends, etc to keep up with the change (and prepare yourself for the next assignment). If this stops becoming 'fun', then that could be a problem. Personally, I love developing - at times, but I find I'm more drawn to PM and business analysis as I move forward. Not sure that's entirely due to getting older but I suspect it plays a part. It seems to be a common shift among developers I've worked with... However, I will say that there's alot of advantage to being a bit older, having seen a number of projects fail and the reasons... Older IT guys will be able to spot the dangerous decisions younger guys can make.
  13. Well, I'm not quite 40 yet but I think there's some truth around this statement:

    --Younger developers are more enthusiastic than older ones.
    I don't buy that at all. I've been in the business since '95 and worked with many unenthusiastic young developers. It's not the age, but the person. Do they enjoy the career? I recently helped a friend by writing a quick C# app for Excel and I STILL enjoy the work. I currently work with a couple guys older than I am and they are hardcore developers. These guys would put lies to those myths in a heartbeat. The only thing I buy is about the hours. That's mainly becaues time has taught me a few things: 1. Heroic measures cannot save the project. 2. The more you know, the smarter you work. Therefore, work smarter, not harder. 3. Watch out for companies that require constant overtime. These places will burn you out and cut you when times get hard. 4. Good managers are ones that appreciate people. They get good because they learned 1,2 an 3 at some point.
  14. Re: Five Myths About Older Developers[ Go to top ]

    The only thing I buy is about the hours. That's mainly becaues time has taught me a few things:

    1. Heroic measures cannot save the project.
    2. The more you know, the smarter you work. Therefore, work smarter, not harder.
    3. Watch out for companies that require constant overtime. These places will burn you out and cut you when times get hard.
    4. Good managers are ones that appreciate people. They get good because they learned 1,2 an 3 at some point.
    What else ? The thread could stop here Guido
  15. Eugene, Thanks for posting this. While I am certainly not an "Older Developer" by most standards, I do agree good organizations should not be indulging in such stereotypes (in part precisely because they are stereotypes). I do have some insight to share here via leading numerous projects in varied environments over the years. I do have to agree that aging has unavoidable cognitive effects most of us cannot escape. However, more experienced workers in a team often do bring insight/judgement/professionalism and do often make it a point to stay abreast as engineers, even if it does sometimes mean burning the mid-night oil every now and then. As to the tolerance for long hours, I'm not sure that is either true or necessarily desirable in the first place. For one thing, I find more experienced workers do have a better handle on real project priorities and tend to be more focused on goals rather than pointless heroism/bravado. Cheers, Reza
  16. Re: Five Myths About Older Developers[ Go to top ]

    As to the tolerance for long hours, I'm not sure that is either true or necessarily desirable in the first place. For one thing, I find more experienced workers do have a better handle on real project priorities and tend to be more focused on goals rather than pointless heroism/bravado
    I would actually posit that long hours are often a symptom of inexperience. As I get more experience I find I am becoming less tolerant of working long hours because of the inexperience/incompetence of others. That doesn't necessarily mean developers. It could be architects, project managers, consultants, etc.
  17. Re: Five Myths About Older Developers[ Go to top ]

    As to the tolerance for long hours, I'm not sure that is either true or necessarily desirable in the first place. For one thing, I find more experienced workers do have a better handle on real project priorities and tend to be more focused on goals rather than pointless heroism/bravado


    I would actually posit that long hours are often a symptom of inexperience. As I get more experience I find I am becoming less tolerant of working long hours because of the inexperience/incompetence of others. That doesn't necessarily mean developers. It could be architects, project managers, consultants, etc.
    Indeed. I remember working on a project about 10 years ago. The PMs said that they'd trebled the estimates we gave, but yet, we should still starting working extra hours to get everything done. The most obvious issue was that if they had indeed told the customers 3 days for every 1 day we told them why did we need to work extra? One of the developers asked why she needed to work extra at all? If she got her stuff done during an 8 hour day and someone else could not, why should she suffer? We never got answers to either questions.
  18. Its the basics missing ![ Go to top ]

    i m in my late 30s but i see that more than age its the quality of education / basics missing. I see these days - 1. most people dont read anything about the language manual as such. they just start coding. 2. There are books like Learn java in 24 hrs. so who has time to read anything from sun website about the language reference. 3. Go to google and you will find code snippet for every problem you have. So people are just copy pasting stuff from random places on the internet without any regard to what is right or wrong. 4. some are just plain stupid who are coding becuase they have a connection with some higher manager. and there are always some more who you all can list :). I think its the same as quality of cheap retail products these days. My Dad's "tube" radio still functions after 50 years. A new fancy radio i bought in BestBuy lasted for just 2 years. Bottom line - software quality these days is bad, but its because we are treating it as a cheap commodity.
  19. I'm in the mid 30s so I wouldn't rank myself among the real seniors, but I find this interesting anyway - see response below each myth:
    Older software developers are more expensive than younger ones, making younger developers more desirable.
    True, but also your employer can charge the customers much more for your work - and is that really less desirable? And as for the end customer, as an experienced developer you give much more value for the money.
    Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge.
    But they also know how to solve their assigned tasks, and don't need to learn everything from scratch...
    Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours) because of family commitments and other attachments that younger workers don't have.
    True - but as pointed out earlier - much of these "painful" hours - is about punching your head into the wall - being stuck into problems an experienced developer would know the way around. The effect of this is also that an older experienced developer is less likely to get "burned out". Long, painful hours puts lot of stress, and sometimes illness on the young developers, and many are out of the business before their 30s.
    Older software developers are less mentally agile than younger ones.
    Older developers does on the other hand have much more routine. They don't have to gather a panel of know-howers in order to solve trivial problems...
    Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones. Younger developers are more enthusiastic than older ones.
    As pointed out, older developers focus more on the task than the excitement of new Java features. Experienced developers look for the right tool for the job, and adapt to new technology with this in mind. Younger developers tend to be enthusiastic about the technology for the sake of technology, rather for the tasks the technology is meant to solve... ---------------------------- So we do still, and always will need the old experienced developers......
  20. Interesting topic.. But i see a tight coupling between age and experience, throughout this discussion.. I agree - with experience everyone gets better.. No questions there.. One suggestion. Why don't you compare older developer (40 yrs) with younger developer (30 yrs) with same years of experience (say 10)? :)
  21. too old ? already ? It was so fast...[ Go to top ]

    Hi, interesting discussion. I'm 37 years old, and I have about 13 years in java development...that means I'm too old to have a position as Senior Java Developer ? Should I go for a team lead or architect position ?
  22. Re: too old ? already ? It was so fast...[ Go to top ]

    Hi,
    interesting discussion.
    I'm 37 years old, and I have about 13 years in java development...that means I'm too old to have a position as Senior Java Developer ? Should I go for a team lead or architect position ?
    Depends. Is that 13 years or 1 year 13 times?
  23. It's other way around. I mean yes you can program in FORTRAN on any language, but folks who do it would screw if they start from Java just as easily. Legacy knowledge just give dipper insight on how thins was evolving and why we went this new direction not the other (like in example with OODBMS vs. RDBMS).

    Regarding comparison of developers with same 10y. experience and different ageâ?¦ it might be same 10y. of Java, but rarely no industry experience 50 y. old just like 25y. old. if we still decide to look at this rare case, weâ??ll see this 25 yrs filled with something â?? since, management, â?¦ and could think of way to utilize it in IT of software industry. But all this trends so meaningless considering how different each person. I could see how in 20s one could be experienced enough to lead team and define architecture and how enthusiastic and adoptive could be other in his 70s.
  24. Worse in Europe[ Go to top ]

    I find that in the US people or more open to people of any age who can do the job. I've literally hear manager folks say in Holland that coders that are older than 30(!) are losers who didn't make it to management. That same company had the hiring policy of getting people straight from colleague so that it 'would be easier to incorporate them in your culture and older people became to rigid in their views anyway'. That's sad, because there are plenty of enthusiastic coders in Holland. But this culture of middle-management doesn't do much for 'coding as a career'. Moving to the US has been very refreshing to me in that respect, and I have coder colleagues of all ages today, who I feel are respected for what they deliver rather than how many birthday candles they can blow out. FWIW, I'm approaching 40 myself and the job market looks fine to me for people with experience.
  25. Same here[ Go to top ]

    I find that in the US people or more open to people of any age who can do the job. I've literally hear manager folks say in Holland that coders that are older than 30(!) are losers who didn't make it to management. ... .
    I agree, in Italy we have the same problem, development is often seen as something that can be bought cheap on the market anyways, because there's always a young kid who likes it enough not to be paid too much. The situation is aggravated by the fact that there is a constant push from technical to managerial positions, based on two false assumptions: 1) being a good technical guy gives you the experience to become a good manager (at least a good manager of other developers...) 2) management should be seen as a reward for people who have worked their asses off on development. We live in a Country where production skills are not valued anymore... Technical career path are long gone, in favour of bullshitting positions...
  26. Re: Same here[ Go to top ]

    I find that in the US people or more open to people of any age who can do the job. I've literally hear manager folks say in Holland that coders that are older than 30(!) are losers who didn't make it to management. ... .


    I agree, in Italy we have the same problem, development is often seen as something that can be bought cheap on the market anyways, because there's always a young kid who likes it enough not to be paid too much. The situation is aggravated by the fact that there is a constant push from technical to managerial positions, based on two false assumptions:
    1) being a good technical guy gives you the experience to become a good manager (at least a good manager of other developers...)
    2) management should be seen as a reward for people who have worked their asses off on development.

    We live in a Country where production skills are not valued anymore... Technical career path are long gone, in favour of bullshitting positions...
    Definitely a European philosophy. I worked for a German based company and the only way you get better paid is to go up the management chain. As predictable, the managers are completely useless except their knowledge of MS project. Dino
  27. Re: Same here[ Go to top ]

    I must state that I don't think management is useless, I myself have an MBA degree (although I started my career as a developer). The best managers I worked with when I was coding had the following qualities: 1) They did not have a technical background 2) They had admiration for technicalities and were often amazed by what developers could produce. 3) They asked developers to give them the kind of technical insight that was needed to better understand the issues they had to deal with. Nothing more than that. 4) They had the ability to create the kind of relaxed environment a team of developers needs to code to high standards, shielding it from the noise of business and political issues. My thesis is: ex developers make worst managers on an average basis, then managers with a stricly managerial culture. Old developers should not be pushed to become managers, and more attention should be devoted to understanding the difference in quality between: 1) A small team of very skilled developers (even if aged) -> High quality, less defects, higher productivity, lower overall costs 2) A bunch of kids hired yesterday by a big consulting company selling them as a team, for a very small rate --> Less quality, more defects, less productivity, higher overall cost , to which the cost of very expensive Highly skilled TERMINATORs (that will come in and save the project melting the kids in acid when things go wrong) must be added...
  28. Re: Same here[ Go to top ]

    My thesis is: ex developers make worst managers on an average basis, then managers with a stricly managerial culture. Old developers should not be pushed to become managers, and more attention should be devoted to understanding the difference in quality between
    Sorry, but I have to disagree. A manager that doesn't have any development experience lacks the tools to know whether his employees are effective or not. Such managers can only judge superficial results. For example, these managers tend to love developers who are really 'fast'. What they don't see is how unmaintainable the code those developers produce is. The developers that have to then try to maintain that code look really bad to the manager because it takes them so long to make 'one little change'. This becomes a self-feeding cycle as the 'fast' developer gets all the new work and the 'slow' maintenance developers can never seem to improve their performance. I think more developers should become managers but such a move should not require that the manager have no technical responsibilities (as is often the case today.) I think that in most other technical fields (e.g. engineering) there is an expectation that managers will be involved and knowledgeable of the work of their subordinates and not just status report readers.
  29. Re: Re: Same here in news[ Go to top ]

    I think the point was more that having managers derived from programmers, without any other qualification, makes bad managers. Just think about it: when somebody got hired as a programmer he had some kind of credentials about his ability to code (a degree, experience, passed some tests maybe, whatever). How does the fact that he spent some years being a programmer (maybe the best in the team) makes him qualified to be a manager?!
  30. Re: Re: Same here in news[ Go to top ]

    I think the point was more that having managers derived from programmers, without any other qualification, makes bad managers.
    Just think about it: when somebody got hired as a programmer he had some kind of credentials about his ability to code (a degree, experience, passed some tests maybe, whatever). How does the fact that he spent some years being a programmer (maybe the best in the team) makes him qualified to be a manager?!
    I agree. The reality is that the main qualification for being a manager is having been a manager. I think training can help too. On a side note, I've never had a manager with any sort of qualification (e.g. MBA.) And it's pretty rare for the best programmer on the team to become a manager. Usually it's the people who are terrible at programming (or hate it) who choose to move into management and usually with very little experience as a programmer. This is a big part of the problem.
  31. Re: Re: Same here in news[ Go to top ]

    I think the point was more that having managers derived from programmers, without any other qualification, makes bad managers.
    Just think about it: when somebody got hired as a programmer he had some kind of credentials about his ability to code (a degree, experience, passed some tests maybe, whatever). How does the fact that he spent some years being a programmer (maybe the best in the team) makes him qualified to be a manager?!


    I agree. The reality is that the main qualification for being a manager is having been a manager. I think training can help too. On a side note, I've never had a manager with any sort of qualification (e.g. MBA.) And it's pretty rare for the best programmer on the team to become a manager. Usually it's the people who are terrible at programming (or hate it) who choose to move into management and usually with very little experience as a programmer. This is a big part of the problem.
    I agree again. You're on a roll today Mr. Watson.
  32. Re: Re: Same here in news[ Go to top ]

    . You're on a roll today Mr. Watson.
    He must have had his "Red Bull". LOL Just in case that goes over like a lead balloon - http://www.youtube.com/watch?v=GOzQWsnqO3c
  33. Re: Re: Same here in news[ Go to top ]

    And it's pretty rare for the best programmer on the team to become a manager. Usually it's the people who are terrible at programming (or hate it) who choose to move into management and usually with very little experience as a programmer. This is a big part of the problem.
    Totally. The issue is that "management" skills are not the same as "programming". Typically, people don't have both skills and never will. Some do. I put in for management job last year, but decided to drop out because it would have been a waste of my talent. At least the company I am at. It is not a technology company. Part of the problem is the standard management structure. Good programmers are not factory workers. Having the same management structure is bad. I use to work at a large "consulting" firm. I joined a team that was a "self-directed" team. We were the only one. We did the best work compared to all the other teams. Oddly enough, almost all were "leaders". Size matters too. Smaller is better. The less efficient or talented (etc) you, as an organization, are, the larger you need to be. The larger you are, the more likely you are to have less talented/efficient/able people. The larger you are, the more management you will need. In addition, you will need processes like ITIL (not bad in and of itself) to manage the largeness. And then people to manage that and management to manage them. Eventually you end up with more non-technical people in IT than technical. As for the old age discussion. Old age is not the problem. People are. Most people want to learn one thing. Young or old. And most can't "know" more than one thing at a time. So, once the head is full, they are done learning. If they have to learn more, they have to dump the other stuff, if they can. In technology, this is a problem. Ignore COBOL for a moment and look at VB. Look at all the people who screamed bloody murder at VB.NET. (some were some valid reasons - large code base). But most were because they would have to learn. And if you have seen the code of many people doing VB.NET you can see they are still doing VB6. And just so everyone knows, I am in Toyota speeding towards 50.
  34. Re: Re: Same here in news[ Go to top ]

    And it's pretty rare for the best programmer on the team to become a manager. Usually it's the people who are terrible at programming (or hate it) who choose to move into management and usually with very little experience as a programmer. This is a big part of the problem.

    Totally. The issue is that "management" skills are not the same as "programming". Typically, people don't have both skills and never will. Some do. I put in for management job last year, but decided to drop out because it would have been a waste of my talent. At least the company I am at. It is not a technology company.

    Part of the problem is the standard management structure. Good programmers are not factory workers. Having the same management structure is bad. I use to work at a large "consulting" firm. I joined a team that was a "self-directed" team. We were the only one. We did the best work compared to all the other teams. Oddly enough, almost all were "leaders".

    Size matters too. Smaller is better. The less efficient or talented (etc) you, as an organization, are, the larger you need to be. The larger you are, the more likely you are to have less talented/efficient/able people. The larger you are, the more management you will need. In addition, you will need processes like ITIL (not bad in and of itself) to manage the largeness. And then people to manage that and management to manage them. Eventually you end up with more non-technical people in IT than technical.

    As for the old age discussion. Old age is not the problem. People are. Most people want to learn one thing. Young or old. And most can't "know" more than one thing at a time. So, once the head is full, they are done learning. If they have to learn more, they have to dump the other stuff, if they can. In technology, this is a problem. Ignore COBOL for a moment and look at VB. Look at all the people who screamed bloody murder at VB.NET. (some were some valid reasons - large code base). But most were because they would have to learn. And if you have seen the code of many people doing VB.NET you can see they are still doing VB6.

    And just so everyone knows, I am in Toyota speeding towards 50.
    Well said and true. I can relate to all of what you said.
  35. Re: Re: Same here in news[ Go to top ]

    Totally. The issue is that "management" skills are not the same as "programming". Typically, people don't have both skills and never will. Some do. I put in for management job last year, but decided to drop out because it would have been a waste of my talent. At least the company I am at. It is not a technology company.
    I've come to the conclusion that you are better off trying to teach developers management skills than trying to teach managers how to understand development. Remember that you don't need all you developers to move into management, just some. The biggest obstacle I see to turning developers into managers is that most organizations say that the minute you are considered a manager, you can't touch or look at code. In my first job, my managers were intimately involved in what I was doing. It wasn't perfect but they knew what I was talking about and whether I was doing a good job. They joined in design meetings acted as arbitrators.
    Part of the problem is the standard management structure. Good programmers are not factory workers. Having the same management structure is bad. I use to work at a large "consulting" firm. I joined a team that was a "self-directed" team. We were the only one. We did the best work compared to all the other teams. Oddly enough, almost all were "leaders".
    This is exactly what I want to change. Managing developers takes a lot of skill. Good developers are self directed. The problem is getting them to direct themselves towards solving the problems that matter to your organization. I've seen very few people do this well.
  36. Re: Same here[ Go to top ]

    My thesis is: ex developers make worst managers on an average basis, then managers with a stricly managerial culture. Old developers should not be pushed to become managers, and more attention should be devoted to understanding the difference in quality between


    Sorry, but I have to disagree. A manager that doesn't have any development experience lacks the tools to know whether his employees are effective or not. Such managers can only judge superficial results. For example, these managers tend to love developers who are really 'fast'. What they don't see is how unmaintainable the code those developers produce is. The developers that have to then try to maintain that code look really bad to the manager because it takes them so long to make 'one little change'. This becomes a self-feeding cycle as the 'fast' developer gets all the new work and the 'slow' maintenance developers can never seem to improve their performance.

    I think more developers should become managers but such a move should not require that the manager have no technical responsibilities (as is often the case today.) I think that in most other technical fields (e.g. engineering) there is an expectation that managers will be involved and knowledgeable of the work of their subordinates and not just status report readers.
    +1 Technical managers who lack technical backgrounds are nightmares. For example, I worked with one who would glom onto the last thing I told him as the cause of any problems. Example: "Hey, I just finished implementing OSCache in the app. Some of those functions will smoke now." Bug comes in... "I think that caching caused a problem." Network problem... "Could this be caused by that cache?" GUI mispelling" "Perhaps we could roll that cache back out." In addition, if that person has favorites, then the Manager always wants to argue about how something is implemented. Manager: "X says that we should do something." That something was usually a pretty bad idea. "
  37. Re: Same here[ Go to top ]

    My thesis is: ex developers make worst managers on an average basis, then managers with a stricly managerial culture. Old developers should not be pushed to become managers, and more attention should be devoted to understanding the difference in quality between


    Sorry, but I have to disagree. A manager that doesn't have any development experience lacks the tools to know whether his employees are effective or not. Such managers can only judge superficial results. For example, these managers tend to love developers who are really 'fast'. What they don't see is how unmaintainable the code those developers produce is. The developers that have to then try to maintain that code look really bad to the manager because it takes them so long to make 'one little change'. This becomes a self-feeding cycle as the 'fast' developer gets all the new work and the 'slow' maintenance developers can never seem to improve their performance.

    I think more developers should become managers but such a move should not require that the manager have no technical responsibilities (as is often the case today.) I think that in most other technical fields (e.g. engineering) there is an expectation that managers will be involved and knowledgeable of the work of their subordinates and not just status report readers.
    I've seen both. Good managers who don't have a software background but are tech savvy enough to pick up what matters and understand their own limitations, and good managers who do have a background and contribute a better long term view on how to run things because they know the realities of the field.
  38. Why did they become managers?[ Go to top ]

    Some programmers become managers because they never cut it as programmers. Their only path upwards was to become a manager rather than creator.
  39. I'm now 44 and have been coding since leaving university in 1988. I saw the change from C to C++ with the corresponding shift in thinking from procedural to object oriented and loved the excitement of learning and adopting the new concepts. Yes I was young then but it wasn't youth that caused me to be enthusiastic about the change - it's just the way my brain is wired. In the nineties I saw the change from C++ to Java and the development efficiencies that brought with it. Again I was enthusiastic about that even though I was older. In recent years (now that I'm *really* old) I'm still open to exploring new technologies and frameworks. In the last few years I've shifted from JSPs to Wicket and Echo frameworks. (ok, bad example, that kind of shift is a no brainer!). I've shifted to using transparent persistence solutions (JDO/Datanucleus) that mean I virtually have a 'zero effort' persistence solution in terms of what I have to actually 'write' to make the persistence happen (bye, bye revolting, hard to maintain, SQL 'glue code'). In recent years I've worked with people 10-15 years younger than me who have bluntly refused to become enthusiastic about a variety of well established or leading edge new technologies. I still see some younger people rigidly stuck in their ways arguing against the benefits of: - object oriented programming and associated best practices. They refuse to 'get' such fundamentally superior concepts such polymorphism and will instead gallantly launch into hacking out a switch/case statement whenever there is some variance in a set of model objects in an application. - new frameworks - they still prefer to 'invent everything from scratch' and continue to argue the benefits of JSPs with Java code embedded right there in the UI layer over modern frameworks with proper separation of concerns. - transparent persistent solutions (JDO/Hibernate etc.,) - they religiously argue that hard hacking SQL glue code throughout their unmaintainable spagetti is sooooo much more efficient and superior to a transparent persistent solution. I agree with the person that said the quality of a programmer has more to do with their attitude than their age. It's all about how a person's brain is wired.
  40. They still prefer to 'invent everything from scratch'...
    This is quite interesting and I hear a lot of this kind of arguments with both older and younger developers. Yet I think the usage of "modern technology" very much depends on the tasks at hand and on your overall environment. For example ORM is an excellent technology if your application is mostly a CRUD, access-by-Id like application with some simple readers. It is still a fairly bad choice if your application is mostly about ad hoc and complex queries on the datasets where a large number of the attribute of any given entity will be ignored. Also a lot of layering that has been introduced in applications is not about separation of concerns or real abstraction but about sticking to some seemingly best practice somebody wrote about in some book with the sole effect that it adds zero to maintainability but a lot to dullness and repetetive work when extensions (on every layer!) are needed. Just take a look at what happened in the last 6 or so years in the J(2)EE space alone: First we were supposed to do everything in Java, then we needed XML "deployment descriptors" to configure everything with servers "warning" us if we wanted to stick to sensible default values than we scrapped EJBs for something called Inversion of Control where we loved to configure *everything* in one large XML file that we replaced by putting everything in the code again into something that loosely resembles compiler directives..... So I think, when people are "starting from scratch" what they strive for is to reduce complexity that older developers just don't see anymore, because they have grown into it (and hopefully with it). For example I think we are still seeing some push back toward two tier application with a lot of logic programmed very close to the data sources, with databases becoming more flexible and ubiquitous by the minute.
  41. Yet I think the usage of "modern technology" very much depends on the tasks at hand and on your overall environment. For example ORM is an excellent technology if your application is mostly a CRUD, access-by-Id like application with some simple readers. It is still a fairly bad choice if your application is mostly about ad hoc and complex queries on the datasets where a large number of the attribute of any given entity will be ignored.
    Many developers, regardless of age, feel compelled to use the most popuplar technology in any given area or the technology that apparent 'gurus' dictate. This is a conservative yet dangerous approach to take, especially in the open source world when newer technologies arise more frequently. In regard to not wanting to pull in all attributes of an entity venture outside your current ORM and google "JDO fetch groups". No one has introduced a law that states that you must use your current ORM.
    Also a lot of layering that has been introduced in applications is not about separation of concerns or real abstraction but about sticking to some seemingly best practice somebody wrote about in some book with the sole effect that it adds zero to maintainability but a lot to dullness and repetetive work when extensions (on every layer!) are needed.

    Just take a look at what happened in the last 6 or so years in the J(2)EE space alone: First we were supposed to do everything in Java, then we needed XML "deployment descriptors" to configure everything with servers "warning" us if we wanted to stick to sensible default values than we scrapped EJBs for something called Inversion of Control where we loved to configure *everything* in one large XML file that we replaced by putting everything in the code again into something that loosely resembles compiler directives.....
    It sounds like you're describing the EJB 1 + 2 disaster and then the declarative XML Spring disaster - adopted blindly by millions like lambs to the slaughter house because, as you say, it was "some seemingly best practice somebody wrote about in some book". The ability to rebel against stupidity is a trait often attributed only to the young but I was in my late thirties/early 40s when I successfully rebelled against aforementioned folly and went direct to transparent persistence (JPOX/DataNucleus) with a light weight IoC framework. I also abandoned JSPs early on in preference for some real component based Java UI frameworks. People... regardless of age you don't have to blindly accept crap that's thrust upon you. If it smells like it and tastes like it, it usually is **it! How some people could withstand the stench of EJB1&2 or Spring XML hell amuses me. You can always vote with your feet folks.
    So I think, when people are "starting from scratch" what they strive for is to reduce complexity that older developers just don't see anymore, because they have grown into it (and hopefully with it). For example I think we are still seeing some push back toward two tier application with a lot of logic programmed very close to the data sources, with databases becoming more flexible and ubiquitous by the minute.
    I agree to an extent. I certainly wouldn't want to revert to entire apps being written mostly as stored procedures. The lack of design and code spagettiarization that encourages is disturbing. Transparent persistence is where it's at for me. For the last five years I've just created domain models as pure, unrestricted POJOs that are persisted transparently for me, even to the point of having metadata automatically generated whenever I change a class diagram. It's not rocket science.
    I've spent time to create such a development environment but the payback is enormous - and this was all done back when I was old. Signed, Benjamin Button ;)
  42. How some people could withstand the stench of EJB1&2 or Spring XML hell amuses me.
    In a few years, we might be amused by how some people could withstand the stench of annotation hell :-) Hey, sounds a young developer? Do the young tend to think the latest is the rightest or correctest or best ?
  43. How some people could withstand the stench of EJB1&2 or Spring XML hell amuses me.


    In a few years, we might be amused by how some people could withstand the stench of annotation hell :-)

    Hey, sounds a young developer? Do the young tend to think the latest is the rightest or correctest or best ?
    As for the "annotation hell" I am fairly sure this is bound to happen. We are now doing declarative programming in a lot of places, where we should really be doing configuration...well what goes around comes around - eventually.
  44. Re: Same here[ Go to top ]

    My thesis is: ex developers make worst managers on an average basis, then managers with a stricly managerial culture. Old developers should not be pushed to become managers, and more attention should be devoted to understanding the difference in quality between


    Sorry, but I have to disagree. A manager that doesn't have any development experience lacks the tools to know whether his employees are effective or not. Such managers can only judge superficial results. For example, these managers tend to love developers who are really 'fast'. What they don't see is how unmaintainable the code those developers produce is. The developers that have to then try to maintain that code look really bad to the manager because it takes them so long to make 'one little change'. This becomes a self-feeding cycle as the 'fast' developer gets all the new work and the 'slow' maintenance developers can never seem to improve their performance.

    I think more developers should become managers but such a move should not require that the manager have no technical responsibilities (as is often the case today.) I think that in most other technical fields (e.g. engineering) there is an expectation that managers will be involved and knowledgeable of the work of their subordinates and not just status report readers.
    I totally agree with this.
  45. The post by andrea Fare has got it all exactly backwards.

    Nontechnical 'managers' are the absolute worst disaster, and the unfortunate trend towards them are part of what is wrong with software today.

    The MBA myth that management is mangement is naieve at best.

    Nobody without a programming background is ever remotely qualified to manage a develoment effort.  I know, having had to put up with these kind of so-called managers.

    A nontechnical manager simply won't know which team members are the good ones, which tasks are the important ones, etc.


    The rest of the thread, about age,experience, etc, shows that there are many experienced developers who know what is going on and care, and that is good.

    I have reluctantly come to the conclusion that programming and software development need to be regulated, as other real professions, including real engineering are.  The business culture is incapable of valuing quality enough, and software is becoming too pervasive to keep ignoring quality.
  46. Re: Worse in Europe[ Go to top ]

    But this culture of middle-management doesn't do much for 'coding as a career'.
    One of the things I'm coming to believe is that there is destructive idea that being a manager means not having any involvement in coding or understanding the technical details. Obviously managers can't spend all of their time coding but I think we need to shift the way we think about management with regard to development.
  47. Re: Worse in Europe[ Go to top ]

    Moreover, Almost all the failed projects have 'managers' that doesnt knows enough about code or are teams of young developers ;-). Yeap, things that are *really* working was done by experienced people. and yes, I am a programmer coding for 20 years and going on... May the source be with you brothers.
  48. Dave, a Java developer, writes: I recently celebrated my 40th birthday. A friend joked, "Hey, guess that means you're too old to program anymore!" I laughed on the outside, but it gave me pause. COBOL guys faced this problem years ago as Java guys were ascending the ranks, and we laughed about legacy code and their inflexibility with new technology. Dave dispels 5 pervasive, negative myths about older software developers. He continues:
    There are a number of myths about older software developers that continue to be perpetuated in IT and software development that somehow put older, experienced workers at a disadvantage in our field. But they're largely crap and considering the degree trends, ignoring everyone 40 and over because we're too old seems plain foolish. Let's debunk these myths one-by-one.
    The myths in question are:

    • Older software developers are more expensive than younger ones, making younger developers more desirable.

    • Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge.

    • Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours) because of family commitments and other attachments that younger workers don't have.

    • Older software developers are less mentally agile than younger ones.

    • Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones. Younger developers are more enthusiastic than older ones.
    Whether you're approaching the 40-year old mark, or have already passed it, sooner or later you'll get a chance to test whether these myths are true. What do you think?
    How old were the guys who developed C, Java, C++, and Ruby?
  49. Dave, a Java developer, writes: I recently celebrated my 40th birthday. A friend joked, "Hey, guess that means you're too old to program anymore!" I laughed on the outside, but it gave me pause. COBOL guys faced this problem years ago as Java guys were ascending the ranks, and we laughed about legacy code and their inflexibility with new technology. Dave dispels 5 pervasive, negative myths about older software developers. He continues:
    There are a number of myths about older software developers that continue to be perpetuated in IT and software development that somehow put older, experienced workers at a disadvantage in our field. But they're largely crap and considering the degree trends, ignoring everyone 40 and over because we're too old seems plain foolish. Let's debunk these myths one-by-one.
    The myths in question are:

    • Older software developers are more expensive than younger ones, making younger developers more desirable.

    • Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge.

    • Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours) because of family commitments and other attachments that younger workers don't have.

    • Older software developers are less mentally agile than younger ones.

    • Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones. Younger developers are more enthusiastic than older ones.
    Whether you're approaching the 40-year old mark, or have already passed it, sooner or later you'll get a chance to test whether these myths are true. What do you think?
    On average, how old were the guys who developed Wicket, RoR, Struts, GWT, ZK, Tapestry, and the host of other popular web development frameworks out there?
  50. Wicket, RoR, Struts, GWT, ZK, Tapestry, and the host of other popular web development frameworks out there?
    Wicket, Tapestry and Struts by people in their 40ties, though with plenty of 20- and 30-something contributors. There's no reason for younger developers to have brilliant ideas and execute those well. Neither is there a reason for discounting older developers in that same area, and most older developers I know have been learning their whole careers and have a wealth of knowledge many younger ones can learn plenty from.
  51. There's no reason for younger developers to have brilliant ideas and execute those wel
    Sorry, that must have been: 'There's no reason for younger developers *not* to have brilliant ideas and execute those wel'
  52. I thinks there's some validity to the old coder stereotypes, but typically I found it with developers > 50s. I work with a guy who's 52 (I'm mid 40's) and he's constantly perusing perfecting his craft, so you cannot judge solely by age. The ones I've experienced problems with were old COBOL and RPG programmers that wouldn't make the move to Java (or OOP in general), RDBMs, etc. Typically, they were into protecting their AS/400 anti-pattern ridden turd piles, working their 40 hour weeks and collecting health benefits. Now the world is much more complex. I think some of us older guys have the patience to do the proper R&D and reinvest in our craft.
  53. I thinks there's some validity to the old coder stereotypes, but typically I found it with developers > 50s. I work with a guy who's 52 (I'm mid 40's) and he's constantly perusing perfecting his craft, so you cannot judge solely by age. The ones I've experienced problems with were old COBOL and RPG programmers that wouldn't make the move to Java (or OOP in general), RDBMs, etc. Typically, they were into protecting their AS/400 anti-pattern ridden turd piles, working their 40 hour weeks and collecting health benefits. Now the world is much more complex. I think some of us older guys have the patience to do the proper R&D and reinvest in our craft.
    The old COBOL and RPG programmers are maddening now that they are unemployed. They network with me and beg me for advice but turn up their noses when I tell them to learn newer skills to get new jobs. They want to stick with COBOL and RPG.
  54. In general, Young guys energy = Old guys inertia
  55. All True[ Go to top ]

    Older software developers are more expensive than younger ones, making younger developers more desirable. - That's why you should opt for the Hyndai instead of the BMW. Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge. - Companies never need to maintain old systems, just write new ones. Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours) because of family commitments and other attachments that younger workers don't have. - Absolutely, why would you want a well rounded individual working for you. Stick with the freaks and just have a good security system for those who go postal. Older software developers are less mentally agile than younger ones. - Since I'm over 40 I can't even think of a reply to this one. Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones. Younger developers are more enthusiastic than older ones. - When you want to develop the next Bob, IBM PC Jr. or whatever, you only want blind enthusiasm. Better than young programmers, hire a remote team, then you can get young inexperienced enthusiastic programmers who for cultural reasons will never question any decisions you'll make. - These's aren't myths, there're FACT.
  56. used to be...[ Go to top ]

    Of course, this was very true when I was young. But now that I'm older, it isn't true anymore ;) Young people seems to think everything is changing very fast, because everyday a new paradigm appears *to them*. When in fact it often is the same old, new coat. Not to say new things don't appear, just not as frequent as most [youngsters] seem to think...
  57. I was younger then...[ Go to top ]

    I posted this back in 2004... but I was younger then ;-) http://weblogs.java.net/blog/2004/12/13/too-old-program
  58. 40 is not OLD![ Go to top ]

    Since when is 40 considered old or older? I just turned 40 and can out run and out jump most people in their 20s. I simply kept myself in shape. And as far as coding is concerned, I am on top of my game. Some of the best software has been written by engineers in their 40s and 50s. I dismiss the myths stated, but I guess that is the point of this thread...they are myths.
  59. First - I'm 58... Wrote my first program (in college way back in 1969) at age 17 (COBOL). My first 3 years as a working programmer were spent writing COBOL and RPG then I was finally able to migrate to Assembly language (IBM mainframe, HP, DEC Vax, 8086) where I spent 6 wonderful years before moving on to C. C, of course, led to C++ and another 17 years of writing code. Then came the Java wave which I've been buried in for the past 10+ years. Now... Now I'm letting Java pay the bills and I'm buried in Objective-C on my Mac systems teaching my self iPhone development (both business and gaming). Do I feel like I'm to old? Heck no!... At night, I sit down in front of my iMac system and hack iPhone code until mid-night (or until the wine runs out). I love doing this... If it wasn't my job it would be my hobby. There's nothing more exciting then stepping through C code with a debugger at mid-night, doing pointer math in your head, and pointing at a hex-display on your second monitor and saying those bits should change on the next instruction to whatever, then stepping over the instruction and watching it all happen. To old? Nope! Just not enough opportunity to do real programming and doing it the right way! :-)
  60. I have a followup post here: http://www.lessonsoffailure.com/developers/habits-kill-career/
  61. ...it's only one difference.
  62. Are the Myths True? Yes and No[ Go to top ]

    I am 52 years old, and would say that I have learned more over the past 10 years than I did in my previous 17 years. During the first 17 years, I developed in one procedural language on one platform. During the past 10 years, I have been employed as a web application developer and have taught myself Java EE, as well as both the Spring and Apache CXF frameworks. I have also picked up HTML, CSS, JavaScript, XML, XSL, Adobe Flex and Flash. In addition, I have learned to manage various application servers and containers, such as Novell Application Server, JBoss, and Tomcat. I have also expanded my database experience from DB2 to include MySQL, Oracle, and Sybase. And, I'm sure I've left off some things. So, clearly, once you hit 40, the ability to learn and adapt is not over. It's a matter of willingness. I will admit that I have known a lot of developers over age 40 who simply admit, "I'm tired of learning and just want to apply what I know until it's time to retire." But, I also have noticed a lot of inflexibility in Java developers. Specifically, they want to do everything in Java. That's the language they know and so the client side has to be done in Java - even though it's not the best language or technology for the job. They are often resistant to learning AJAX or Flash or Flex or Silverlight. Inflexibility, along with an unwillingness to learn and adapt, is not an age factor. It is an ambition factor, or a lack thereof. Unfortunately, lack of ambition often comes with the decreasing energy that accompanies aging. But, I've seen a lot of lazy a** 20 and 30 years olds as well. R. Grimes
  63. Are the Myths True? Yes and No[ Go to top ]

    Heh.  We've just had a *major* business realignment, and our shop of top-notch hard-core Java developers has been told that we'll be moving to .NET.  As one of the senior developers (in my late 40s), I have the dubious honor of being one of the "expeditionary forces" to do preliminary investigation and make technology recommendations.  Two of the other guys on the team are in their 40s, and we have a couple of junior developers in their 20s on the team as well.  Guess who's having the most trouble coming up to speed on the new tech?  At least once a day one or the other of the younger developers tags me and asks "Can you take a look at this and tell me why it won't work?  I did it just like the tutorial showed..."  And it usually turns out to be something missing or just plain wrong in the tutorial.  We older guys just work around the problem (and bitch about how lousy the docs are), but the younger ones get that "deer in the headlights" look and are completely lost.  I put it down to not having enough opportunities to screw up, so they don't recognize it when they see it.  Either that, or development's just gotten so much easier with all these pre-packaged libraries and hand-holding IDEs that it's hard to screw up on a regular basis... (When's the last time you had a syntax error caught by the compiler?)
  64. Older software developers are more expensive than younger ones but can be object managed instead of task managed therefor making them more cost effective. Older software developers legacy knowledge is most often associated with development discipline which is much harder to learn than any new technology. Technology revolutions are rare. Most new technology innovations are additive. Older software developers work smarter not harder. My current oversight contract demonstrates the increased workload correlation to increased defects. Smarter not harder should be the buzzword. Older software developers' mental agility is more related to breadth of experience. Younger software developers are more likely to show several years repeating the same experience on their resume. Older software developers' attitudes may be considered jaded when they offer their experience in order to prevent a project from following a less desirable path. Younger developers seem more enthusiastic about coding than modeling. Very few younger developers have any interest in committing their software designs to Word / Excel documents.
  65. Why stop at our profession. I regularly see doctors in their sixties. A doctor making a mistake may cost you your life. Why is software so different. Medical technology moves just as fast.
    • Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours) because of family commitments and other attachments that younger workers don't have.

    • Older software developers are less mentally agile than younger ones.
    On the 1st point, I thought that long hours were no longer seen as an essential or desirable mode of working. Also, in my 20s I had too much of a social life going on to let work get in the way. It's safe to say that is no longer the case. On the 2nd point, this may be true (this may be something to do with the social life I had in my 20s).
  66. This is the most ridiculous and jaded thing I've ever seen. I'll argue the converses of every point and you judge which seems more true: the originals or mine. 1) Younger programmers are more desirable to younger managers who see bottom lines, not results. Older programmers are more mature, experienced and efficient. How many twenty somethings have you watched use their exhuberance to run in circles to solve a problem while a more mature programmer quietly solves it directly in ten minutes? 2) Those who got into software for financial or other wrong reasons are less flexible to learn new skills. It's not about age. They're less flexible period. They work for a paycheck. People of any age (IE Mr. Gosling himself) got into programming for the sheer joy of it. Age is irrelevant. 3) Older programmers have touched many frameworks, many technologies and many buzz words that younger ones simply have no clue of. They are more efficient, more open minded and simply bring alot more to the table. I think we're basing this on a stereotype of one burned out programmer everyone has seen at the office. Let's then also count the other side of the coin. What about the five new graduates who rely on friends for every piece of code they write and bail out on the career because it wasn't as "easy" as they thought? 4) Again, nothing to do with age. It's simply one personality type. How many webinars do you see given enthusiastically by 40-something or 50-something year old programmers? 5) How many cocky younger programmers do you see who already know everything and refuse to learn things because they "already know better than older people do"? I'm thinking many more than "jaded older programmers".
  67. you are 40 years old and calling yourself an older developer? man you lost me already .. go find a life.
  68. I can think of several things that contribute to the myths. More Expensive: Well that depends. Not all, but many older developers are still programming because they love it and it is a form of art to them. They want it done right and want their work to last long after they have left the project. They take pride in their work (Hopefully not to the detriment of embracing change). That should mean designing systems that not only meet functional requirements but are also secure, dependable, maintainable, and cost effective. That does not come cheap up front. I think creating design documents is a good idea. This adds cost, but helps avoid design disasters and leaves behind a blueprint for those that need to maintain the application in their absence. Too many young programmers jump from job to job, whipping out some code and leaving a mess in their trail for other to maintain. Sure it may have passed QA at the time of release, but then came time when major enhancements are needed and the new developers have to waste days wading through mud and debating the cost of starting over. Inflexible and not capable to learn new technologies: Again that depends. Like mentioned by others, a lot of newer technologies are just a repeat of older themes. I love learning newer frameworks, but that does not mean I want to use all of them in projects. Some have a certain Cool-Factor, but it is not always worth the risk to use them. Sure I love Spring and use it when I can, but that does not mean I use it as a rubber stamp. So just because there is a resistance to use does not mean a resistance to learn. Can't work the long hours: I think this has to do with priorities. LOL, how many times have you looked at someone’s code and wondered: "They must have been up too late writing that code or were smoking something at the time". Working late is a sign of either poor project management and/or personal time prioritization. I can understand working late because you are in the middle of some exciting development that keeps you glued to the PC, but not because the project is pushing it. Less mentally agile: This is probably a true statement. Let’s face it, as we get older are brains do deteriorate some. But then again I am not sidetracked by the cares of my younger coworkers. I find it very easy to focus on a problem and work thru it. My problem is I can probably refactor it to death. I want perfection where the younger developer will find a quick fix and move on, leaving a mud ball for others to refactor or completely redo. More jaded and cynical: Junk is junk and poorly managed projects are self evident. I guess older developers can spot it easier. I wonder if younger developers have ever worked on well run projects and architected systems to be able to appreciate a Hero-Free mentality. When you have seen chaos lead to unneeded stress and project failure, you naturally want to avoid it.
  69. XML Hell[ Go to top ]

    You know, I must be the only one who missed the fact that XML config files were hell. I have built some really, really big websites using Spring MVC and all that configuration went into a bunch of xml files. I would estimate that the amount of time on those projects devoted to 'xml' was somewhere around .05% of the total project time. I wish someone had told me sooner that there was a "better way" and that I could have cut that .05% down to .03% or maybe even .02%. Chris
  70. Re: XML Hell[ Go to top ]

    The point is that there were a lot of projects where every object that one could imagine to be "mocked" or "injected" actually *were* injected. Personally I never had much of a problem with EJB 2.1 deployment descriptors unless someone thought they needed to list all the possible defaults explictly in the XML (and I never had much of a problem with the "desaster" of looking up EJBs, since there is precious little difference of configuring the lookup name in an XML file to configuring the Injection strategy in an XML file...).
  71. Great reply[ Go to top ]

    You know, I must be the only one who missed the fact that XML config files were hell. I have built some really, really big websites using Spring MVC and all that configuration went into a bunch of xml files. I would estimate that the amount of time on those projects devoted to 'xml' was somewhere around .05% of the total project time. I wish someone had told me sooner that there was a "better way" and that I could have cut that .05% down to .03% or maybe even .02%.

    Chris
    I thought the same thing when I read the whining about Spring xml files, but your response was priceless. Loved it. In my view, Java wasn't worth learning prior to the advent of IoC frameworks and the addition of annotations and Java generics. R. Grimes
  72. Re: Great reply[ Go to top ]

    In my view, Java wasn't worth learning prior to the advent of IoC frameworks and the addition of annotations and Java generics.

    R. Grimes
    While I like those additions as much as you do, I think without it Java is still a pretty capable language. You need people with solid OO skills to make something decent out of it though.
  73. Re: Great reply[ Go to top ]

    In my view, Java wasn't worth learning prior to the advent of IoC frameworks and the addition of annotations and Java generics.

    R. Grimes


    While I like those additions as much as you do, I think without it Java is still a pretty capable language. You need people with solid OO skills to make something decent out of it though.
    Well, Java could have been a better language without the 'eraser' generics as it is in Java 1.5/1.6.
  74. Re: XML Hell[ Go to top ]

    You know, I must be the only one who missed the fact that XML config files were hell. I have built some really, really big websites using Spring MVC and all that configuration went into a bunch of xml files. I would estimate that the amount of time on those projects devoted to 'xml' was somewhere around .05% of the total project time. I wish someone had told me sooner that there was a "better way" and that I could have cut that .05% down to .03% or maybe even .02%.

    Chris
    That .05% probably drove your software design a lot more than you realized. Personally I can't imagine anyone being truly happy with any web mvc framework and being happy with it, certainly not when you need to configure them through XML. Stuff like:
    to 'wire' your actions together has bloody little to do with an elegant programming model no matter how much actual time you spend on it. There was a time not very long ago and every friggin framework in the Java universe started out with it's own XML oriented DSL 'just because' and then worked towards solving their problem. XML has been grossly overused, and often it was just the lack of imagination (or maybe design skills) that drove that. As for Spring, I think calling that XML hell is a bit much, but using a framework like Guice is really a breath of fresh air compared to it. Anyway, this reply probably comes across harsher than I mean it. I'm just very opinionated now that I've been in the field for a few years ;-)
  75. Re: XML Hell[ Go to top ]

    You know, I must be the only one who missed the fact that XML config files were hell. I have built some really, really big websites using Spring MVC and all that configuration went into a bunch of xml files. I would estimate that the amount of time on those projects devoted to 'xml' was somewhere around .05% of the total project time. I wish someone had told me sooner that there was a "better way" and that I could have cut that .05% down to .03% or maybe even .02%.

    Chris
    You and me both. The "Spring XML == BAD" guys need to learn a new song. "You didn't like Spring XML." Fine. Some of us had no issues with this aspect of Spring. It is 2010. Let it go.
  76. Re: XML Hell[ Go to top ]

    Some of us had no issues with this aspect of Spring. It is 2010. Let it go.
    Yet there are some lessons to learn here which is where "the older developer" comes in. Any new technology will be marketed as the next silver bullet by its evangelists. When spring took off you could witness dozens of projects where everything was configured for IoC injection. Every bloody bean instance was created by the spring factory and had to implement an interface that never meritted more than a single, trivial implementation. The weight that put on the development lifecycle was just enormous. At the end of day, it turned out that IoC "configuration" is meaningful mostly in the places where you would use "pull" configuration anyway and at system boundaries where you really need proper encapsulation. So, with each new technology, you need to strike a balance to decide (a) if you use it and (b) to what extent and (c) will it really replace an existing technology with something simpler or at least add real value and of course (d) is there some other technology or implementation that just suits the actual problem domain better. As a simple example I am sure that there are dozens of projects that would profit from using Wicket rather than JSF and iBatis rather than hibernate (and in fact vice versa!).
  77. Re: XML Hell[ Go to top ]

    Some of us had no issues with this aspect of Spring. It is 2010. Let it go.


    Yet there are some lessons to learn here which is where "the older developer" comes in. Any new technology will be marketed as the next silver bullet by its evangelists. When spring took off you could witness dozens of projects where everything was configured for IoC injection. Every bloody bean instance was created by the spring factory and had to implement an interface that never meritted more than a single, trivial implementation. The weight that put on the development lifecycle was just enormous.

    At the end of day, it turned out that IoC "configuration" is meaningful mostly in the places where you would use "pull" configuration anyway and at system boundaries where you really need proper encapsulation.

    So, with each new technology, you need to strike a balance to decide (a) if you use it and (b) to what extent and (c) will it really replace an existing technology with something simpler or at least add real value and of course (d) is there some other technology or implementation that just suits the actual problem domain better.

    As a simple example I am sure that there are dozens of projects that would profit from using Wicket rather than JSF and iBatis rather than hibernate (and in fact vice versa!).
    I hate to tell you, but any technology can be misused. Just become some developers, both young and old potentially misused Spring doesn't condemn the technology. I don't agree with your assessment. Every bean *YOU* implement caused *YOUR* projects issues. Not mine. At the end of day, you didn't like it and perhaps didn't really understand how to use it. Fine. Just understand that some of us know how to use it better and let it go.
  78. Re: XML Hell[ Go to top ]

    I hate to tell you, but any technology can be misused. Just become some developers, both young and old potentially misused Spring doesn't condemn the technology.

    I don't agree with your assessment. Every bean *YOU* implement caused *YOUR* projects issues.

    Not mine.

    At the end of day, you didn't like it and perhaps didn't really understand how to use it. Fine. Just understand that some of us know how to use it better and let it go.
    I appreciate you being a super developer, yet I have seen dozens of projects where exactly that happened - too many layers, each abstracted away and injected using XML. It was not uncommon to do that. They were not *MY* projects by the way. I have no real issue with people using IoC technology being it Spring or some other, when it makes sense. Strangely, technology is very often used because it is cool or because some manager wants you to use it, rather because it solved any problems. The amount of abstractions that did not abstract from anything that were created in the IoC heydays is just overwhelming. Just take a look at some codebases that were created around 4, 5 years ago...
  79. Re: XML Hell[ Go to top ]

    I hate to tell you, but any technology can be misused. Just become some developers, both young and old potentially misused Spring doesn't condemn the technology.

    I don't agree with your assessment. Every bean *YOU* implement caused *YOUR* projects issues.

    Not mine.

    At the end of day, you didn't like it and perhaps didn't really understand how to use it. Fine. Just understand that some of us know how to use it better and let it go.

    I appreciate you being a super developer, yet I have seen dozens of projects where exactly that happened - too many layers, each abstracted away and injected using XML. It was not uncommon to do that. They were not *MY* projects by the way.

    I have no real issue with people using IoC technology being it Spring or some other, when it makes sense. Strangely, technology is very often used because it is cool or because some manager wants you to use it, rather because it solved any problems.

    The amount of abstractions that did not abstract from anything that were created in the IoC heydays is just overwhelming. Just take a look at some codebases that were created around 4, 5 years ago...
    I never said that there were not bad projects and I'm not super. I just hate to see good technology get a bad rap because of bad use. Cars are not bad because people can wreck them. Heck 4 or 5 years ago you had to convince management to use Spring.
  80. I have always been cursed with a good memory for some matters, and therefore I remember when I left college, and would meet up with the 'young dogs' every now and then to talk about those 'older colleagues' who had 'lost touch with the newest technology' and were 'waiting to retire'. When we caught up a few years ago -- all forty-somethings by now--, I heard the same people say that 'those youngsters were inexperienced' and 'had more mouth than qualities' ...then I realised that this is how it goes...men are always just talking to secure their own identities... Kees
  81. To start with, let’s start talking about more experienced and less experienced developers instead of young and old; to talk about age is both meaningless and discriminatory. With the only exception that experienced developers are normally more expensive, all the other 4 "myths" listed are rubbish; any hiring manager that believes in them is a total incompetent and is not doing his company any favours. Bjarne Stroustrup, Scott Meyers, James Gosling and Joshua Bloch have well passed their 30s but you can bet your sweet life that I would like to have any of them onboard any non-trivial C++ or Java project - if only I could afford it. This is not ballet or football; we are talking about engineering here. In engineering all levels of seniority have their role to play. Besides technical know-how and sound project planning, the single most important success factor in any non-trivial software engineering project is diversity in the team. Software engineering, or development if you prefer, is a career for life, not just something you do for a few years after graduation before moving into "something else". That’s ridiculous.
  82. Age is not an issue[ Go to top ]

    There are a number of taxonomies adequate to classify developers with the intent to make decisions concerning building up a team. Nevertheless, age is not one of them. People are different, but it doesn´t come with age. Moreover, there is no scientific proof of the declared myths.