7 ms·

Age discrimination being rampant in our industry is a fantastic opportunity for an astute hiring manager. I go out of my way to hire older devs that are eschew

Age discrimination being rampant in our industry is a fantastic opportunity for an astute hiring manager. I go out of my way to hire older devs that are eschewed by typical Bay Area startups. I can get a seasoned pro with a solid background in C - and other more trendy languages - for about the same price of a 3-years-working-experience "senior dev" who likely was battlefield commissioned into the role at their last startup. The typical solid dev can only put in 4, maybe 5-6 hours of actual good coding a day. If you know how to run a tight org - and not a sweatshop of 20-year olds pulling 16 hour days where only maybe 2-3 hours are actual programming time - then older devs are a fantastic bargain. Plus, when it comes time to architect something complex, I have found older devs typically create more simple and elegant solutions just because they have been exposed to more. Of course, I do run into the occasional stuck-in-the-mud older dev who is very slow to adapt to current trends and wants everyone else to get off their lawn. That has been a rare exception to my overall experience and I don't think it should be used to stereotype the older devs as a group.

mlthoughts2018 8y ago
> The typical solid dev can only put in 4, maybe 5-6 hours of actual good coding a day. Outside of extremely rare triage situations, this limit is true for all developers, regardless of age or quality of output. Beyond about the 6 hour mark, people can force themselves to sit in a chair and hit keys on a keyboard like the Swedish chef from the muppets, but it's pure management denial to believe those hours count as "productivity" and in fact when the defect rates start to get high and fatigue compounds and morale drops, it's really anti-productive. Really, younger age is just usually correlated with fewer extracurricular responsibilities, i.e. home repair, health maintenance, domestic responsibilities, marriage, children, etc. These things tend to increase with age, making it a scheduling impossibility for older workers to sit in the chair at 8 pm going "hur duh dur" while slapping keys.
- always_good 8y ago
  > this limit is true for all developers Maybe sober, but that's not the limit once you factor in the rampant use of amphetamine.
  - bmpafa 8y ago
    This is probably a myth, but I've heard Kerouac wrote On the Road practically in a single sitting thanks to the peppy magic of Benzedrine, aka Bennies, a _widely_ available inhalant & pill form of amphetamine.
    - 52-6F-62 8y ago
      I think it was 3 weeks and a roll of teletype paper so that once he started he wouldn't have to stop to even change the paper. edit: https://www.theguardian.com/books/2008/dec/02/jack-kerouac-road-birmingham https://www.theguardian.com/books/2008/dec/02/jack-kerouac-r... the "scroll"
  - opportune 8y ago
    True but generally not good information to propagate, not for selfish reasons, just because it sets an unreasonably high standard It’s true you can knock out a 10-20hr session in essentially one sitting, but it’s not a good habit to set for yourself or the industry
- hcoura 8y ago
  I have recently started working remotely and dealing with my own productivity as opposed to have some expectations of work hours has been an interesting challenge. Since I log my own hours I became full aware of this 6 hours "ceiling" in the long term, for a few days I could work for many more hours, but that would have a big price to pay in future productivity. In the beginning I felt bad, as if I was not able to produce as much as other people leading to a lot of anxiety. As I realized that my actual productivity was going up, compared to my older self and other peers, I embraced it. Now I work 6 productive hours and to me that's 8 hours of work, my results are better month by month, my quality of life is better and my anxiety is more controlled. Everybody wins.
  - Retric 8y ago
    Based on what I have seen, even 6 productive hours is a high bar even in people that stay in the office 10+ hours a day. Simple things like getting a drink of water or going to the bathroom often take far longer in a cubicle farm than at home. Add having nothing to do, random IT problems, chit chat, checking the phone or other web browsing etc, and the average IT worker might be doing 3-4.
  - baxtr 8y ago
    Please, please, please let everybody come to this conclusion. How much better would the world be as place. I’ve wasted many hours of my time at work, not working, which is so sad
    - logfromblammo 8y ago
      I personally allocate the work day into one 4-hour block as my "big pipe", one 2-hour block as my "little pipe", and let the other 2 hours be "fluff". For limited intervals, I can combine the two pipes into one "mega pipe", to get a "big pipe" task done faster, but it takes a toll over time. The "big pipe" can also theoretically be split into two more temporary "little pipes", but in general, I usually want to have the "big pipe" around to get something important done, and multitasking on three things creates too much organizational overhead, so that also takes a toll. "Fluff" time is for sitting in meetings or writing reports, as work functions, or for just looking busy. I intentionally avoid doing real work that requires any focus or creativity in the fluff slot. After six hours of real work, any more time spent doing the same thing starts to become counterproductive. So just leave it for tomorrow. I have been more productive while explicitly dedicating 2 hours a day to getting nothing useful done, than when trying to stay focused on one thing for 8 hours, and ending up goofing off, getting sidetracked, or procrastinating for some amount of time anyway. That's the theory, anyway. My current employer doesn't keep my pipelines reliably filled. During the dry spells, I have a hard time expanding the fluff slot to more than two hours, and end up doing stuff like coding stupid CLI games, or vectorizing the company logo, or setting up a new vanilla VM that I might not ever use.
- bartread 8y ago
  Maybe you also accrue enough wisdom to know that after that 5-6 hours, however productive you might feel, what you write is going to be garbage so the smartest thing to do is stop, unless you want to waste even more time sorting out the mess later. I can still code for longer than this, from time to time, but only if I already know exactly where I'm going. Even then it's playing with fire.
ryanmonroe 8y ago
> I go out of my way to hire older devs that are eschewed by typical Bay Area startups Going "out of [your] way" to hire older devs sounds like age discrimination. AFAIK, age discrimination in this direction isn't illegal in America, but it seems odd that you would respond to an article decrying age-discrimination by proudly declaring that you discriminate too, in the opposite direction. Maybe you just meant that you almost always find the qualities/compensation-demands you're looking for in older applicants rather than younger ones, but your phrasing doesn't seem to indicate that.
- scarface74 8y ago
  You're right it's not illegal and all you have to do is say you want someone with at least 20 years of professional software development experience...
- Moto7451 8y ago
  It's not age discrimination if you accept and do not otherwise discriminate against young/younger candidates. There's a lot that goes into recruiting. Optimizing your job descriptions, creating multiple job descriptions, and targeting your ad spend are all things that can affect the age, race, gender, education level, etc of the people you reach without being discriminatory. In fact, you should do this to be inclusive. There are a lot of unconscious things hiring managers do that remove themselves from the running of highly qualified candidates. Want to remove yourself from consideration from young talented female developers? Create a laundry list of "requirements" even though you consider them "nice to haves." Also add plenty of trigger words to make your business seem unattractive. https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless-theyre-100-qualified https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless... https://www.forbes.com/sites/hbsworkingknowledge/2016/12/14/how-to-take-gender-bias-out-of-your-job-ads/#21863e951024 https://www.forbes.com/sites/hbsworkingknowledge/2016/12/14/... Avoiding hurting yourself in the eyes of candidates you'd like to include is far from being discriminatory to other groups.
  - throwawaymath 8y ago
    > There's a lot that goes into recruiting. Optimizing your job descriptions, creating multiple job descriptions, and targeting your ad spend are all things that can affect the age, race, gender, education level, etc of the people you reach without being discriminatory. Wait...isn't this exactly what the article is talking about?
bmpafa 8y ago
I understand your intent and I'm not suggesting you oughta do anything differently, but I am not sure how net good it is that older devs' labor is being sold at a discount. My understanding is that silicon valley hasn't cured aging yet, so until that happens, this seems like yet another market distortion that favors employers at the expense of labor (or 'YAMDTFEAEL' for short)
bartread 8y ago
Five of the six people on my team, including me, are over 30; four of us are over 40. I must admit that although devs with that level of experience are "expensive", they start to look a lot cheaper when you realise the additional value they add due to experience. Software development, as with many things in life, often follows the adage that you get what you pay for. (It should go without saying, but it's a sad inevitability that there will be exceptions.)
- andrei_says_ 8y ago
  A part of the higher pay grade is that the majority of the mistakes one must make to gain experience points have been paid for. Also, maturity often comes with a reduction of the ego-driven drama friction which can make people so much more pleasant to work with.
- tabtab 8y ago
  But many startups are "ship first, debug later". When it's a pump-and-dump fashion contest, younger fingers are probably better: a fast BS-nozzle to get VC attention. If instead you want your infrastructure to last 5 or 10 years and not get hacked, then experience will pay off.
  - tluyben2 8y ago
    The over 40s I know are also able to produce working crap faster than the young-uns. If you call it a prototype (so the goal is showing functionality that works but later it will be tossed out and redone) then hiring me is probably going to produce a better one (less bugs and will probably last until the startup runs out of money) then it would with a ‘team of young ninjas’. As PR for VCs I can see a bunch of young people might look better (not to many VCs I talk to but I so not live in the US), but if you want ‘faster’, a 35+ who kept up is probably faster and cheaper. In my experience. When the company grows I definitely would not want a CTO under 35/40.
    - tabtab 8y ago
      Re: The over 40s I know are also able to produce working [prototypes] faster... Not necessarily if it has to be built in some stack or language flavor of the month (and VC's check). If you change entire tool-sets every 18 months, I bet the younger folks will be able to re-learn faster. I'm 40+ myself, and am saying this from experience. It's unfortunate our industry is so fad-driven, but I didn't create humans, I just work among them. I recommend one focus on a domain (insurance IT, healthcare IT, etc.) when they get around 40. Your domain knowledge will have market value. Reformatting your head all the time is not a good career strategy for most. (There is some value to some new IT things, but a good portion is hype and gimmicks.)
gowld 8y ago
Why would you go out of your way?
- astrodust 8y ago
  You could actually read the comment and have your confusion resolved.
andrei_says_ 8y ago
It is really ironic that an industry focused on engineering can act in such an irrational manner. Long hours in the office chair is only a measurement of management’s failure to pay attention to the metrics that matter. Strongly preferring less experienced devs because they can work longer (which they need to, partially to compensate for their lack of experience), is both tragic and comical. It’s likely the pay is lower for the younger devs but the very practice of working long hours has been proven as detrimental to quality.
- mmt 8y ago
  > an industry focused on engineering I'm not sure that's the whole story, though, especially considering how much of the "industry" is VC-driven and how few VCs are engineers.
- rhizome 8y ago
  You ever play the video game "World of Goo?" That's my image of what shortsighted engineering can get you. Trailer: https://www.youtube.com/watch?v=-A_JfkzPwww https://www.youtube.com/watch?v=-A_JfkzPwww
twothamendment 8y ago
I like to think of it as hiring people with actual years of experience. I don't care what their age is or their title. Are they a senior developer only because they have 6 more months than the other guy at the startup or are they senior because they've had 6 jobs over twice as many years? Those years add add experience in doing things the wrong way and in ways that work.
stcredzero 8y ago
Are you hiring?
eksemplar 8y ago
I prefer hiring people in their 30ies. It’s the perfect mix of being old enough to be practical and patient and young enough to still be cheap. The cheap bit comes from being in the Danish public sector where seniority gives automatic pay increases that you can’t legally turn down, so there is that. I do wonder why people wouldn’t hire older programmers or engineers though. A lot of them are still extremely nerdy about their hobby, they have profound amounts of experience and they’ll typically both be able to follow orders and voice their opinions. Often they’ll have a good grip on work life balancing as well, making them less prone to stress. I’m not sure ageism is really a big problem though. I haven’t seen any unemployment numbers on old programmers being huge, though I will admit that fear of abuse was one of the reasons I went into management. That being said, I do think people should plan their staff to be without huge age gaps. It’s one of the few things that has an empirical proven negative effect on teams. But that goes both ways.
- taurath 8y ago
  Couple points I’ve seen that can knock older (and not wiser) devs - * fixing the problems they had at their last company, inappropriately so to the point of over-engineering. Sometimes it’s not elegant, but hardened against the wrong things * insistence on older technologies and patternss that they’re familiar with even if not concise
  - mistrial9 8y ago
    maybe you mean 'patterns'
    - taurath 8y ago
      My pphones autocorrect might not be working correctly ;)
- cmcginty 8y ago
  >I prefer hiring people in their 30ies. >I’m not sure ageism is really a big problem though. I'm not sure you can put both those statements together without sounding uninformed.
throwawayWSk24h 8y ago
Are you sure? I hired these seasoned pros you talk about. I have a team of 12 developers and 3 of these seasoned pros that are about 60+ yrs old. C/C++ devs. They are the worst performing on the team. The 22/23yrs old are running circles around them. They are slow, taking 2-5x times as long to finish their task. It's no better in quality. They are seriously struggling to pick up new technologies. I'm a minority so I'm pretty open minded and built a diverse team race, gender, age, sexuality, whatever. Oh yeah, they are also very well paid due to the past experience! Sometimes as much as twice as the new grads. The one quality that scares the crap out of me for the future is ... Please do note that I'm not talking about 10hr shifts, work on weekends kinda environment. Just the typical come in at 9ish leave at 6 environment. I'm getting older myself too so I understand.
- busterarm 8y ago
  What are your quality metrics and over what timescale are you measuring? Are you treating everyone in your organization as equivalent resources or are you allocating people based on strengths/specialties? Having a heterogeneous team with breadth of experience across the stack helps to isolate you from the real business risks of group-think and "not knowing what you don't know". It's a hedge and a pillar of a resilient, long-term-oriented organization. If you just want to have a get-shit-done culture, move fast and pivot/abort when things get bad, you probably want all 20 year olds. However, if you look at the organizational structure of banks, who are literally in the business of managing business risk, you will see diversity and redundancy in hiring. Side note: Every single time I've seen a complaint about X group doesn't work as effectively as Y group, it's almost always a management misallocation of (human) resource. Not calling you out specifically, just wondering how much thought was put into team/work structure.

mlthoughts2018 8y ago

> The typical solid dev can only put in 4, maybe 5-6 hours of actual good coding a day. Outside of extremely rare triage situations, this limit is true for all developers, regardless of age or quality of output. Beyond about the 6 hour mark, people can force themselves to sit in a chair and hit keys on a keyboard like the Swedish chef from the muppets, but it's pure management denial to believe those hours count as "productivity" and in fact when the defect rates start to get high and fatigue compounds and morale drops, it's really anti-productive. Really, younger age is just usually correlated with fewer extracurricular responsibilities, i.e. home repair, health maintenance, domestic responsibilities, marriage, children, etc. These things tend to increase with age, making it a scheduling impossibility for older workers to sit in the chair at 8 pm going "hur duh dur" while slapping keys.

always_good 8y ago
> this limit is true for all developers Maybe sober, but that's not the limit once you factor in the rampant use of amphetamine.
- bmpafa 8y ago
  This is probably a myth, but I've heard Kerouac wrote On the Road practically in a single sitting thanks to the peppy magic of Benzedrine, aka Bennies, a _widely_ available inhalant & pill form of amphetamine.
  - 52-6F-62 8y ago
    I think it was 3 weeks and a roll of teletype paper so that once he started he wouldn't have to stop to even change the paper. edit: https://www.theguardian.com/books/2008/dec/02/jack-kerouac-road-birmingham https://www.theguardian.com/books/2008/dec/02/jack-kerouac-r... the "scroll"
- opportune 8y ago
  True but generally not good information to propagate, not for selfish reasons, just because it sets an unreasonably high standard It’s true you can knock out a 10-20hr session in essentially one sitting, but it’s not a good habit to set for yourself or the industry
hcoura 8y ago
I have recently started working remotely and dealing with my own productivity as opposed to have some expectations of work hours has been an interesting challenge. Since I log my own hours I became full aware of this 6 hours "ceiling" in the long term, for a few days I could work for many more hours, but that would have a big price to pay in future productivity. In the beginning I felt bad, as if I was not able to produce as much as other people leading to a lot of anxiety. As I realized that my actual productivity was going up, compared to my older self and other peers, I embraced it. Now I work 6 productive hours and to me that's 8 hours of work, my results are better month by month, my quality of life is better and my anxiety is more controlled. Everybody wins.
- Retric 8y ago
  Based on what I have seen, even 6 productive hours is a high bar even in people that stay in the office 10+ hours a day. Simple things like getting a drink of water or going to the bathroom often take far longer in a cubicle farm than at home. Add having nothing to do, random IT problems, chit chat, checking the phone or other web browsing etc, and the average IT worker might be doing 3-4.
- baxtr 8y ago
  Please, please, please let everybody come to this conclusion. How much better would the world be as place. I’ve wasted many hours of my time at work, not working, which is so sad
  - logfromblammo 8y ago
    I personally allocate the work day into one 4-hour block as my "big pipe", one 2-hour block as my "little pipe", and let the other 2 hours be "fluff". For limited intervals, I can combine the two pipes into one "mega pipe", to get a "big pipe" task done faster, but it takes a toll over time. The "big pipe" can also theoretically be split into two more temporary "little pipes", but in general, I usually want to have the "big pipe" around to get something important done, and multitasking on three things creates too much organizational overhead, so that also takes a toll. "Fluff" time is for sitting in meetings or writing reports, as work functions, or for just looking busy. I intentionally avoid doing real work that requires any focus or creativity in the fluff slot. After six hours of real work, any more time spent doing the same thing starts to become counterproductive. So just leave it for tomorrow. I have been more productive while explicitly dedicating 2 hours a day to getting nothing useful done, than when trying to stay focused on one thing for 8 hours, and ending up goofing off, getting sidetracked, or procrastinating for some amount of time anyway. That's the theory, anyway. My current employer doesn't keep my pipelines reliably filled. During the dry spells, I have a hard time expanding the fluff slot to more than two hours, and end up doing stuff like coding stupid CLI games, or vectorizing the company logo, or setting up a new vanilla VM that I might not ever use.
bartread 8y ago
Maybe you also accrue enough wisdom to know that after that 5-6 hours, however productive you might feel, what you write is going to be garbage so the smartest thing to do is stop, unless you want to waste even more time sorting out the mess later. I can still code for longer than this, from time to time, but only if I already know exactly where I'm going. Even then it's playing with fire.

ryanmonroe 8y ago

> I go out of my way to hire older devs that are eschewed by typical Bay Area startups Going "out of [your] way" to hire older devs sounds like age discrimination. AFAIK, age discrimination in this direction isn't illegal in America, but it seems odd that you would respond to an article decrying age-discrimination by proudly declaring that you discriminate too, in the opposite direction. Maybe you just meant that you almost always find the qualities/compensation-demands you're looking for in older applicants rather than younger ones, but your phrasing doesn't seem to indicate that.

scarface74 8y ago
You're right it's not illegal and all you have to do is say you want someone with at least 20 years of professional software development experience...
Moto7451 8y ago
It's not age discrimination if you accept and do not otherwise discriminate against young/younger candidates. There's a lot that goes into recruiting. Optimizing your job descriptions, creating multiple job descriptions, and targeting your ad spend are all things that can affect the age, race, gender, education level, etc of the people you reach without being discriminatory. In fact, you should do this to be inclusive. There are a lot of unconscious things hiring managers do that remove themselves from the running of highly qualified candidates. Want to remove yourself from consideration from young talented female developers? Create a laundry list of "requirements" even though you consider them "nice to haves." Also add plenty of trigger words to make your business seem unattractive. https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless-theyre-100-qualified https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless... https://www.forbes.com/sites/hbsworkingknowledge/2016/12/14/how-to-take-gender-bias-out-of-your-job-ads/#21863e951024 https://www.forbes.com/sites/hbsworkingknowledge/2016/12/14/... Avoiding hurting yourself in the eyes of candidates you'd like to include is far from being discriminatory to other groups.
- throwawaymath 8y ago
  > There's a lot that goes into recruiting. Optimizing your job descriptions, creating multiple job descriptions, and targeting your ad spend are all things that can affect the age, race, gender, education level, etc of the people you reach without being discriminatory. Wait...isn't this exactly what the article is talking about?

bmpafa 8y ago

I understand your intent and I'm not suggesting you oughta do anything differently, but I am not sure how net good it is that older devs' labor is being sold at a discount. My understanding is that silicon valley hasn't cured aging yet, so until that happens, this seems like yet another market distortion that favors employers at the expense of labor (or 'YAMDTFEAEL' for short)

bartread 8y ago

Five of the six people on my team, including me, are over 30; four of us are over 40. I must admit that although devs with that level of experience are "expensive", they start to look a lot cheaper when you realise the additional value they add due to experience. Software development, as with many things in life, often follows the adage that you get what you pay for. (It should go without saying, but it's a sad inevitability that there will be exceptions.)

andrei_says_ 8y ago
A part of the higher pay grade is that the majority of the mistakes one must make to gain experience points have been paid for. Also, maturity often comes with a reduction of the ego-driven drama friction which can make people so much more pleasant to work with.
tabtab 8y ago
But many startups are "ship first, debug later". When it's a pump-and-dump fashion contest, younger fingers are probably better: a fast BS-nozzle to get VC attention. If instead you want your infrastructure to last 5 or 10 years and not get hacked, then experience will pay off.
- tluyben2 8y ago
  The over 40s I know are also able to produce working crap faster than the young-uns. If you call it a prototype (so the goal is showing functionality that works but later it will be tossed out and redone) then hiring me is probably going to produce a better one (less bugs and will probably last until the startup runs out of money) then it would with a ‘team of young ninjas’. As PR for VCs I can see a bunch of young people might look better (not to many VCs I talk to but I so not live in the US), but if you want ‘faster’, a 35+ who kept up is probably faster and cheaper. In my experience. When the company grows I definitely would not want a CTO under 35/40.
  - tabtab 8y ago
    Re: The over 40s I know are also able to produce working [prototypes] faster... Not necessarily if it has to be built in some stack or language flavor of the month (and VC's check). If you change entire tool-sets every 18 months, I bet the younger folks will be able to re-learn faster. I'm 40+ myself, and am saying this from experience. It's unfortunate our industry is so fad-driven, but I didn't create humans, I just work among them. I recommend one focus on a domain (insurance IT, healthcare IT, etc.) when they get around 40. Your domain knowledge will have market value. Reformatting your head all the time is not a good career strategy for most. (There is some value to some new IT things, but a good portion is hype and gimmicks.)

gowld 8y ago

Why would you go out of your way?

astrodust 8y ago
You could actually read the comment and have your confusion resolved.

andrei_says_ 8y ago

It is really ironic that an industry focused on engineering can act in such an irrational manner. Long hours in the office chair is only a measurement of management’s failure to pay attention to the metrics that matter. Strongly preferring less experienced devs because they can work longer (which they need to, partially to compensate for their lack of experience), is both tragic and comical. It’s likely the pay is lower for the younger devs but the very practice of working long hours has been proven as detrimental to quality.

mmt 8y ago
> an industry focused on engineering I'm not sure that's the whole story, though, especially considering how much of the "industry" is VC-driven and how few VCs are engineers.
rhizome 8y ago
You ever play the video game "World of Goo?" That's my image of what shortsighted engineering can get you. Trailer: https://www.youtube.com/watch?v=-A_JfkzPwww https://www.youtube.com/watch?v=-A_JfkzPwww

twothamendment 8y ago

I like to think of it as hiring people with actual years of experience. I don't care what their age is or their title. Are they a senior developer only because they have 6 more months than the other guy at the startup or are they senior because they've had 6 jobs over twice as many years? Those years add add experience in doing things the wrong way and in ways that work.

stcredzero 8y ago

Are you hiring?

eksemplar 8y ago

I prefer hiring people in their 30ies. It’s the perfect mix of being old enough to be practical and patient and young enough to still be cheap. The cheap bit comes from being in the Danish public sector where seniority gives automatic pay increases that you can’t legally turn down, so there is that. I do wonder why people wouldn’t hire older programmers or engineers though. A lot of them are still extremely nerdy about their hobby, they have profound amounts of experience and they’ll typically both be able to follow orders and voice their opinions. Often they’ll have a good grip on work life balancing as well, making them less prone to stress. I’m not sure ageism is really a big problem though. I haven’t seen any unemployment numbers on old programmers being huge, though I will admit that fear of abuse was one of the reasons I went into management. That being said, I do think people should plan their staff to be without huge age gaps. It’s one of the few things that has an empirical proven negative effect on teams. But that goes both ways.

taurath 8y ago
Couple points I’ve seen that can knock older (and not wiser) devs - * fixing the problems they had at their last company, inappropriately so to the point of over-engineering. Sometimes it’s not elegant, but hardened against the wrong things * insistence on older technologies and patternss that they’re familiar with even if not concise
- mistrial9 8y ago
  maybe you mean 'patterns'
  - taurath 8y ago
    My pphones autocorrect might not be working correctly ;)
cmcginty 8y ago
>I prefer hiring people in their 30ies. >I’m not sure ageism is really a big problem though. I'm not sure you can put both those statements together without sounding uninformed.

throwawayWSk24h 8y ago

Are you sure? I hired these seasoned pros you talk about. I have a team of 12 developers and 3 of these seasoned pros that are about 60+ yrs old. C/C++ devs. They are the worst performing on the team. The 22/23yrs old are running circles around them. They are slow, taking 2-5x times as long to finish their task. It's no better in quality. They are seriously struggling to pick up new technologies. I'm a minority so I'm pretty open minded and built a diverse team race, gender, age, sexuality, whatever. Oh yeah, they are also very well paid due to the past experience! Sometimes as much as twice as the new grads. The one quality that scares the crap out of me for the future is ... Please do note that I'm not talking about 10hr shifts, work on weekends kinda environment. Just the typical come in at 9ish leave at 6 environment. I'm getting older myself too so I understand.

busterarm 8y ago
What are your quality metrics and over what timescale are you measuring? Are you treating everyone in your organization as equivalent resources or are you allocating people based on strengths/specialties? Having a heterogeneous team with breadth of experience across the stack helps to isolate you from the real business risks of group-think and "not knowing what you don't know". It's a hedge and a pillar of a resilient, long-term-oriented organization. If you just want to have a get-shit-done culture, move fast and pivot/abort when things get bad, you probably want all 20 year olds. However, if you look at the organizational structure of banks, who are literally in the business of managing business risk, you will see diversity and redundancy in hiring. Side note: Every single time I've seen a complaint about X group doesn't work as effectively as Y group, it's almost always a management misallocation of (human) resource. Not calling you out specifically, just wondering how much thought was put into team/work structure.