Ask HN: Do startups hire 50+ year old programmers?(US)
16 comments
I always frown a little when my older (by a dozen years or so) co-workers get frustrated when moving to new tech, like git. :( Too often they'll bristle at the mere suggestion that they should keep the dedicating an hour or two of their spare time each week/month to reading and learning new things.
Its not hard, regardless of obligations outside of the office. You can't just sit back and rest on the stuff you learned 10 years ago...
Its not hard, regardless of obligations outside of the office. You can't just sit back and rest on the stuff you learned 10 years ago...
Why should they do this in their spare time? If it is important to the business, shouldn't the employers provide time for their employees to learn new technologies?
There's nothing wrong with requireing your employer to do that. To me, it seems like a transition away from being an engineer to an employee. Keeping up with the latest and greatest, learning new stuff keeps you active in your profession. When you're passive about about that stuff, your job hunting prospects decline. In the worst case, you're literally totally dependent on that single employer, because there's nothing else you can do.
Because the business will be able to find someone who is willing to learn in their spare time. Besides, the great thing about being a programmer is not that you have to learn new things but that you get to.
"the business will be able to find someone who is willing to learn in their spare time. Besides, the great thing about being a programmer is not that you have to learn new things but that you get to."
Huh. I love to learn new things, but I hate learning boring technologies that re-solve solved problems. Especially when the old, boring technologies are serving me well.
If I could reclaim the hours I spent learning git (which is only a marginal net improvement over svn), I have a long backlog of CS papers about everything from image classification to distributed systems design. Those problems are interesting. Learning another version-control system is not interesting (and the same goes for: editors, make systems, debuggers, and to some extent, programming languages. I don't want to spend hundreds of hours learning another syntactic variant of Algol or Lisp unless I need it for something.) But now that I'm proficient with git, I can guarantee that some obnoxious fanboy is going to come along and force me to switch to some whizzy new version control system that promises to solve all my problems and give me a pony. It's the way of the world, but I'm still waiting for my pony.
When I was younger, I'd get distracted by any flash in the pan. Now I'm more conservative about what I'll pick up. Maybe that kind of conservatism is part of what you're paying for when you hire an experienced employee. After all, someone who won't waste hundreds of developer hours switching your whole company to the newest flavor of version control (without sufficient justification for the cost) is a benefit to the bottom line.
Huh. I love to learn new things, but I hate learning boring technologies that re-solve solved problems. Especially when the old, boring technologies are serving me well.
If I could reclaim the hours I spent learning git (which is only a marginal net improvement over svn), I have a long backlog of CS papers about everything from image classification to distributed systems design. Those problems are interesting. Learning another version-control system is not interesting (and the same goes for: editors, make systems, debuggers, and to some extent, programming languages. I don't want to spend hundreds of hours learning another syntactic variant of Algol or Lisp unless I need it for something.) But now that I'm proficient with git, I can guarantee that some obnoxious fanboy is going to come along and force me to switch to some whizzy new version control system that promises to solve all my problems and give me a pony. It's the way of the world, but I'm still waiting for my pony.
When I was younger, I'd get distracted by any flash in the pan. Now I'm more conservative about what I'll pick up. Maybe that kind of conservatism is part of what you're paying for when you hire an experienced employee. After all, someone who won't waste hundreds of developer hours switching your whole company to the newest flavor of version control (without sufficient justification for the cost) is a benefit to the bottom line.
If you don't see the value of Git, I doubt you learned anything at all. You may know some git commands, but you didn't learn anything.
You sound exactly like the stereotype the original post describes.
You sound exactly like the stereotype the original post describes.
I don't know if you can draw that drastic of a conclusion from his post without some other knowledge of his particular situation. For some people Git offers very little advantage over SVN, a small team with a single desktop or embedded produce is not going to see the same advantages of a DCVS system that a massive web team does that is seeing daily releases. As such a developer with their use case may feel that the effort to learn it for their situation was not worth the effort.
"For some people Git offers very little advantage over SVN, a small team with a single desktop or embedded produce is not going to see the same advantages of a DCVS system"
I disagree, actually. Small, informal teams can use pretty much whatever they want with little penalty, and may actually benefit from having distributed repositories. Larger teams rarely need distributed version control (there's almost always a canonical central repository), and are also the ones most penalized by the complexity of git.
Git is a complex, confusing beast with a high potential for mistakes. There are some nice things about it, but (from personal experience) it also tends to create as many new problems as it solves. These problems are amplified on large teams.
I disagree, actually. Small, informal teams can use pretty much whatever they want with little penalty, and may actually benefit from having distributed repositories. Larger teams rarely need distributed version control (there's almost always a canonical central repository), and are also the ones most penalized by the complexity of git.
Git is a complex, confusing beast with a high potential for mistakes. There are some nice things about it, but (from personal experience) it also tends to create as many new problems as it solves. These problems are amplified on large teams.
From the parent:
> I always frown a little when my older (by a dozen years or so) co-workers get frustrated when moving to new tech, like git.
The business IS providing the time, they just don't want it. I'm sure most developers on HN has tried and been successful in getting their employer to try out new technologies (in order to learn) and paying for conferences and books.
If you don't jump at these opportunities and instead let yourself stagnate, you're gradually signing away more exciting career opportunities (including working in a startup) and the right to complain about your employer marginalising you over new hot-shot developers.
> I always frown a little when my older (by a dozen years or so) co-workers get frustrated when moving to new tech, like git.
The business IS providing the time, they just don't want it. I'm sure most developers on HN has tried and been successful in getting their employer to try out new technologies (in order to learn) and paying for conferences and books.
If you don't jump at these opportunities and instead let yourself stagnate, you're gradually signing away more exciting career opportunities (including working in a startup) and the right to complain about your employer marginalising you over new hot-shot developers.
This is one of those assertions that is simultaneously true and irrelevant. A developer who is comfortable in git is better than a developer who's only willing to use Clearcase. How they get to be one or the other doesn't play into the value calculation. "That's not fair" is one of the least compelling arguments in business.
But then, I strongly object to the notion that older developers are likely to push back on (say) git. More likely, given the developers over 40 that I have known, is that the developer is likely to think that choice of VCS is banal; older developers are less likely to fetishize git or hg, which is a productivity trap for developers who are passionate about their VCS.
But then, I strongly object to the notion that older developers are likely to push back on (say) git. More likely, given the developers over 40 that I have known, is that the developer is likely to think that choice of VCS is banal; older developers are less likely to fetishize git or hg, which is a productivity trap for developers who are passionate about their VCS.
Who would you rather hire/work-with?
* the developer (of any age) who keeps up with technology in their spare time
* the developer (of any age) who refuses to keep up with new technology or who demands that the business provide the time for learning new things
I know what my answer is.
To be clear - this is completely orthogonal to the question of whether or not companies should provide time for this.
I'm talking about the difference between someone who takes responsibility for their own career path vs. someone who expects the company to do it for them.
I know what my answer is.
To be clear - this is completely orthogonal to the question of whether or not companies should provide time for this.
I'm talking about the difference between someone who takes responsibility for their own career path vs. someone who expects the company to do it for them.
I personally don't agree with this, I think as a professional it is our obligation to keep our skills relevant by whatever means, if we want to work on newer technology. If we don't we can choose to sunset. That being said, when I am in an authoritative position in my organizations I always give my developers free time to improve skills but I personally don't think it should be expected.
Because employers could just replace you. The same way a person is supposed to take care of his own choice of career and the education that goes with it, one should keep up to date with the novelties himself.
Of course, if we are talking about some obscure technology/process that the employer has chosen (ISO 98823:4343 for example), then the employer should provide the training.
I'm 49 years old.
Currently I write python, php, (and all the usual web scripting like js, html, css etc, etc) and c.
I've always written c. But spanning my carrer (life) I've written Assembler, BASIC, Xbase, Pascal, COBOL, & Ada. I've worked on various database systems including DB2, Oracle, Sybase and straight betrieve.
I've worked on various systems including (my very first HeathKit and TRS 80), Wang, Dec VAX, Netware, BeOS, IBM 360 and AS400's, most of the various UNIX's and of course all the popular OS's of today.
I use Git. I also use SVN. And I even use CVS (if I must).
This idea that us "older" programmers are resistant to change is ridiculous. If you want to get the "older guys" using Git explain why. I can't tell you how many times I hear younger programmers bashing other languages and tools. And rarely do they know what they are talking about.
PS: Let me add; I'm in management now - translation- programmers work for me. But I still write code. With them. On the same projects. For several reasons: (1) I enjoy it. (2) I better understand what they are writing. (3) I like to say to clients "I wrote that". That feels good.
Currently I write python, php, (and all the usual web scripting like js, html, css etc, etc) and c.
I've always written c. But spanning my carrer (life) I've written Assembler, BASIC, Xbase, Pascal, COBOL, & Ada. I've worked on various database systems including DB2, Oracle, Sybase and straight betrieve.
I've worked on various systems including (my very first HeathKit and TRS 80), Wang, Dec VAX, Netware, BeOS, IBM 360 and AS400's, most of the various UNIX's and of course all the popular OS's of today.
I use Git. I also use SVN. And I even use CVS (if I must).
This idea that us "older" programmers are resistant to change is ridiculous. If you want to get the "older guys" using Git explain why. I can't tell you how many times I hear younger programmers bashing other languages and tools. And rarely do they know what they are talking about.
PS: Let me add; I'm in management now - translation- programmers work for me. But I still write code. With them. On the same projects. For several reasons: (1) I enjoy it. (2) I better understand what they are writing. (3) I like to say to clients "I wrote that". That feels good.
My uncle is in his early 50's and is a Cobol programmer. Been doing it for a long time now. For him, programming isn't fun any more. Its just a way to make a decent living doing something he knows well. But he really doesn't like it.
I've talked to him about learning some new languages and expanding his opportunities, but he's more interested in moving into some other kind of work like teaching.
I think it depends on the person, whether they do it for life or because its what they know.
I've talked to him about learning some new languages and expanding his opportunities, but he's more interested in moving into some other kind of work like teaching.
I think it depends on the person, whether they do it for life or because its what they know.
I'm 49 also, and I still write C and Python. I also have a lot of experience of scaling things operationally, so we have many things to provide. I love learning the new things, if they help me do my job better - like git (HATE svn. HATE). I quickly can spot the fads and will look at them and wait (scala, erlang) for the right place to use them.
> I quickly can spot the fads
I'm 44 and this is a very under-rated skill that older developers bring to the table. And one that only experience can teach. The grand-parent posted mentioned it as well when he talks about younger programmers bashing other tools and languages but rarely know what they are talking about.
I love hiring older developers for this reason. The problem is finding an older developer who 1) wants to continue to write code, 2) has kept up-to-date with their skills and 3) is looking for a job. That is a rarity indeed. Having just gone through the search for a new hire I can tell you there were plenty of older developers who applied that didn't have proper skills and none who kept up with technologies.
I'm 44 and this is a very under-rated skill that older developers bring to the table. And one that only experience can teach. The grand-parent posted mentioned it as well when he talks about younger programmers bashing other tools and languages but rarely know what they are talking about.
I love hiring older developers for this reason. The problem is finding an older developer who 1) wants to continue to write code, 2) has kept up-to-date with their skills and 3) is looking for a job. That is a rarity indeed. Having just gone through the search for a new hire I can tell you there were plenty of older developers who applied that didn't have proper skills and none who kept up with technologies.
I care about quality output, pure and simple. Productivity in our technology stack is what I'm looking for in candidates. I've encountered basically two types of programmers who are 50+ (my guess on their age, based on resume dates).
Those who (still) possess that curiosity to learn and the drive to create. They may not be completely current with every late-breaking technology (show me anyone who really does, for that matter), but they embrace change and strive for improvement. They are the ones that make you forget about age -- young, old or somewhere in between.
And then there are those who seem like they walked in with their high-school letterman's jacket on, hanging on something they did years and years ago -- and having trouble transitioning to today's world.
While many people associate those 50 and older as "seniors", not everyone maintains senior-level status in this business. As we all age, we would do well to remember to rely on our natural instincts for curiosity and learning to keep the fires stoked and remain relevant in an industry that will continue to change for years to come.
Those who (still) possess that curiosity to learn and the drive to create. They may not be completely current with every late-breaking technology (show me anyone who really does, for that matter), but they embrace change and strive for improvement. They are the ones that make you forget about age -- young, old or somewhere in between.
And then there are those who seem like they walked in with their high-school letterman's jacket on, hanging on something they did years and years ago -- and having trouble transitioning to today's world.
While many people associate those 50 and older as "seniors", not everyone maintains senior-level status in this business. As we all age, we would do well to remember to rely on our natural instincts for curiosity and learning to keep the fires stoked and remain relevant in an industry that will continue to change for years to come.
I hope you remember there age, or more specifically what comes with serious experience, when they e.g. look at the symptoms of a bug and say "It's going to be there" (in the code) and are right more often than not. That's something I achieved in C/C++, but only after, say, a decade and a half of working with them. (And this does translate to newer stuff where no one can have that much experience, although of course not as well).
Or take architecture. I know I've done a good job there when mine solves problems I didn't consciously anticipate. Again, that took nearly 2 decades from when I first started programming including a lot of reading on good software design, starting in that first year of programming ('77-8) and never stopping. Heck, the older you are, the more time you've had to read and grok the classics.
Hmmm, to finish with a riff on some other observations in this discussion, the normal, average outcome of a startup is failure. Perhaps one should consider non-normal approaches to staffing, like recruiting one or more grey-beards of the right sort who can save you days, weeks, even man-months of effort on individual things because of their experience. To paraphrase Scott Adams, sometimes you have the option of working harder or smarter. The latter frequently wins.
Or take architecture. I know I've done a good job there when mine solves problems I didn't consciously anticipate. Again, that took nearly 2 decades from when I first started programming including a lot of reading on good software design, starting in that first year of programming ('77-8) and never stopping. Heck, the older you are, the more time you've had to read and grok the classics.
Hmmm, to finish with a riff on some other observations in this discussion, the normal, average outcome of a startup is failure. Perhaps one should consider non-normal approaches to staffing, like recruiting one or more grey-beards of the right sort who can save you days, weeks, even man-months of effort on individual things because of their experience. To paraphrase Scott Adams, sometimes you have the option of working harder or smarter. The latter frequently wins.
Youth is not a skill. I don't hire green college grads. And I look at anyone with less than 10 years of experience with suspicion. Knowing Ruby or Scala or whatever syntax is fine, but it's far less important than the underlying skills: OO design, distributed systems, threading... Specific languages and frameworks come and go. Many of the twenty somethings don't really understand that.
As for working 80 hour weeks, you're fooling yourself if you think people of any age can do that productively for an extended period of time. Plenty of research exists on that topic.
The key to hiring is to hire only A players who will be highly productive and produce quality code. In my experience A players are not twenty somethings. Do you think Delta Force recruits green beans fresh out of boot camp? Absolutely not. They recruit from the Rangers and Special Forces. Of course we can't all hire A players. But I can.
As for working 80 hour weeks, you're fooling yourself if you think people of any age can do that productively for an extended period of time. Plenty of research exists on that topic.
The key to hiring is to hire only A players who will be highly productive and produce quality code. In my experience A players are not twenty somethings. Do you think Delta Force recruits green beans fresh out of boot camp? Absolutely not. They recruit from the Rangers and Special Forces. Of course we can't all hire A players. But I can.
Actually, I like hiring one or so nearly green college grads of the right sort, who are willing to be mentored. As long as they are self-directed, can start working given basic directions and then ask you the right questions (my favorite example from a guy who'd only done C++: "where is new in C?" "ah, in C we malloc...."), they can be very productive and follow your vision. And as they learn, help to refine it.
I believe in trying to balance your team. A very few green apprentices (too many take too much time), enough seriously experienced masters (you're not likely to get many) and then journeymen in the middle, all of these aspiring to reach higher levels.
I believe in trying to balance your team. A very few green apprentices (too many take too much time), enough seriously experienced masters (you're not likely to get many) and then journeymen in the middle, all of these aspiring to reach higher levels.
Here is an honest answer that you won't hear from many others. Startups are not the best option for 50 year olds.
Most 50 year olds demand high salaries, aren't willing to work long hours (let alone nights and weekends), are far less familiar with new technologies and less willing to learn, and are much more cynical than 20 somethings. The risk, uncertainty, and low structure environment of a startup is just a bad fit for the age group in general.
Our society hasn't yet adapted to the fact that as people get older in technology, they get less competent but demand higher and higher salaries due to their increasing fixed costs (mortgage, etc.).
Those who will argue with you about the above facts want to eat their cake and keep it too, like the women who want to have kids and pregnancy and a social life but also want to make it big at a high tech startup. People do not want to acknowledge that tradeoffs exist: that women with young children can't put in long hours or that old folks just aren't as plastic and supple.
Some engineers age like Ken Ritchie, and stay sharp. Some go into management or do consulting on legacy systems. Those are all legit options. A 50 something should have enough savings to bankroll his own startup; that too is a legit option. But working at a YC-style startup is not likely to be a good fit.
Most 50 year olds demand high salaries, aren't willing to work long hours (let alone nights and weekends), are far less familiar with new technologies and less willing to learn, and are much more cynical than 20 somethings. The risk, uncertainty, and low structure environment of a startup is just a bad fit for the age group in general.
Our society hasn't yet adapted to the fact that as people get older in technology, they get less competent but demand higher and higher salaries due to their increasing fixed costs (mortgage, etc.).
Those who will argue with you about the above facts want to eat their cake and keep it too, like the women who want to have kids and pregnancy and a social life but also want to make it big at a high tech startup. People do not want to acknowledge that tradeoffs exist: that women with young children can't put in long hours or that old folks just aren't as plastic and supple.
Some engineers age like Ken Ritchie, and stay sharp. Some go into management or do consulting on legacy systems. Those are all legit options. A 50 something should have enough savings to bankroll his own startup; that too is a legit option. But working at a YC-style startup is not likely to be a good fit.
Our society hasn't adapted to the fact that people get less competent and unjustifiably more expensive with age because it isn't true.
People who get less competent get less competent; people who demand unjustifiable compensation demand unjustifiable compensation. Some of those people are 50+. Some of them are 25. Some 20-somethings code for 2 years, write an O'Reilly book, and then reposition themselves as "architects". So many young people did this with the title "CTO" that the term "CTO" got tainted.
This is something I was taught in 3rd grade, but apparently hasn't percolated into the public school system, so we're having to teach it to adults at great expense: one needs to be vigilant about prejudice.
Or, in some cases not, because one of the subtexts behind ageism is that talent is getting more and more expensive, and firms want to avoid engaging with that reality. At least 21 year olds come bundled with the pretense of inexperience, so you can pay them 40% of scale.
If I sound self-righteous about this, I apologize; I'm really not upset by it, because it is one of the more easily exploitable market inefficiencies our industry cultivates. You guys pay for the "Rails programmer" who foreaches through N+1 queries because they don't grok SQL joins; I'll pick up the 50 year olds who've shipped Lisp and written RISC assembly.
People who get less competent get less competent; people who demand unjustifiable compensation demand unjustifiable compensation. Some of those people are 50+. Some of them are 25. Some 20-somethings code for 2 years, write an O'Reilly book, and then reposition themselves as "architects". So many young people did this with the title "CTO" that the term "CTO" got tainted.
This is something I was taught in 3rd grade, but apparently hasn't percolated into the public school system, so we're having to teach it to adults at great expense: one needs to be vigilant about prejudice.
Or, in some cases not, because one of the subtexts behind ageism is that talent is getting more and more expensive, and firms want to avoid engaging with that reality. At least 21 year olds come bundled with the pretense of inexperience, so you can pay them 40% of scale.
If I sound self-righteous about this, I apologize; I'm really not upset by it, because it is one of the more easily exploitable market inefficiencies our industry cultivates. You guys pay for the "Rails programmer" who foreaches through N+1 queries because they don't grok SQL joins; I'll pick up the 50 year olds who've shipped Lisp and written RISC assembly.
[deleted]
Dude, you're arguing from stereotypes. Saying "as people get older they get less competent" is just silly; I can tell there's the same distribution in competence in a set of 25- year-olds that there is in 55-year-olds.
(It is true that the 25-yos haven't had a chance to fall behind yet, and a lot of them will. But those are the same bozos who show up in the DailyWTF today doing dumb stuff with modern tools, and in 30 years nobody will care about their code.)
And "a 50-something should have enough savings to bankroll his own startup" is a close second in silly. Evidently you haven't watched too closely what's happened in finance over the last thirty years. (A few folks have done well, many more have been close to wiped-out. Look up "Pareto distribution".)
Mature engineers are just as capable or running on adrenaline (or just the high of building somthing really great) when needed as younger folks. However, they're more likely to know whether you really have an event calling for adrenaline, or are just looking to get 80 hours of work for 40 hours of salary. (Or are building something truly great as opposed to just a clone of something that's been done and failed six times already, but in node.js this time instead of Rails)
They're also less likely to have the gullibility to buy into the equity compensation fantasies that a lot of startups lean on (while the VC guys stack the deck, and the techs show up here later whining about "those bastards screwed me on my stock options")
(It is true that the 25-yos haven't had a chance to fall behind yet, and a lot of them will. But those are the same bozos who show up in the DailyWTF today doing dumb stuff with modern tools, and in 30 years nobody will care about their code.)
And "a 50-something should have enough savings to bankroll his own startup" is a close second in silly. Evidently you haven't watched too closely what's happened in finance over the last thirty years. (A few folks have done well, many more have been close to wiped-out. Look up "Pareto distribution".)
Mature engineers are just as capable or running on adrenaline (or just the high of building somthing really great) when needed as younger folks. However, they're more likely to know whether you really have an event calling for adrenaline, or are just looking to get 80 hours of work for 40 hours of salary. (Or are building something truly great as opposed to just a clone of something that's been done and failed six times already, but in node.js this time instead of Rails)
They're also less likely to have the gullibility to buy into the equity compensation fantasies that a lot of startups lean on (while the VC guys stack the deck, and the techs show up here later whining about "those bastards screwed me on my stock options")
An implication of the parent comment is that hiring at 50+ incurs adverse selection, because 50+ developers that are on the market for full time work have demonstrated inability to succeed in startups.
This sentiment misunderstands startups as well as software development careers.
Most people will not succeed with startups.
Most people who start companies fail.
Most professional developers will opt not to start companies because the (low) success rate is obvious.
The people who succeed with startups are not particularly likely to be amazing software developers. In fact, the impedance mismatch between raw programming talent and software startup success is one of the more irritating things about working in startups.
There's no statistical observation to be made from someone's lack of success building companies.
This sentiment misunderstands startups as well as software development careers.
Most people will not succeed with startups.
Most people who start companies fail.
Most professional developers will opt not to start companies because the (low) success rate is obvious.
The people who succeed with startups are not particularly likely to be amazing software developers. In fact, the impedance mismatch between raw programming talent and software startup success is one of the more irritating things about working in startups.
There's no statistical observation to be made from someone's lack of success building companies.
> The people who succeed with startups are not particularly likely to be amazing software developers. In fact, the impedance mismatch between raw programming talent and software startup success is one of the more irritating things about working in startups.
From my experience, the people who succeed and reach the big payout tend to be the bottom quarter in terms of developer skill. They had an idea early enough, new enough or with enough impact to gain traction. Later professional developers come in to clean up their mess.
Unfortunately, after the payout these low-skill (from a development sense) tend to think they were actually highly skilled. They don't repeat their first success, often they become "Angel investors".
On the other hand. If you're hiring you should simply enjoy this large, un-mined vein of talent. Hopefully your competition doesn't catch on.
From my experience, the people who succeed and reach the big payout tend to be the bottom quarter in terms of developer skill. They had an idea early enough, new enough or with enough impact to gain traction. Later professional developers come in to clean up their mess.
Unfortunately, after the payout these low-skill (from a development sense) tend to think they were actually highly skilled. They don't repeat their first success, often they become "Angel investors".
On the other hand. If you're hiring you should simply enjoy this large, un-mined vein of talent. Hopefully your competition doesn't catch on.
I don't agree with you on "they get less competent but demand higher and higher salaries due to their increasing fixed costs (mortgage, etc.)"
I am an 'old guy' and although I may not be typical, I have easily averaged 10 to 15 hours learning new technology every week for the last 20 years. My Dad is another good example of my point: he is 90, still a member of the National Academy of Sciences, and in the last 5 years has learned to be an expert an 3D animation and video production - as a hobby.
Also, once people reach a certain age, assuming that they are good at what they do, they are economically very stable, many of us no longer have mortgages, only work because we love it, etc.
Anyway, your comments seem innocent enough, and I don't want to get on your case, but stereotypes and generalizations are sometimes not true :-)
I am an 'old guy' and although I may not be typical, I have easily averaged 10 to 15 hours learning new technology every week for the last 20 years. My Dad is another good example of my point: he is 90, still a member of the National Academy of Sciences, and in the last 5 years has learned to be an expert an 3D animation and video production - as a hobby.
Also, once people reach a certain age, assuming that they are good at what they do, they are economically very stable, many of us no longer have mortgages, only work because we love it, etc.
Anyway, your comments seem innocent enough, and I don't want to get on your case, but stereotypes and generalizations are sometimes not true :-)
he is 90, still a member of the National Academy of Sciences, and in the last 5 years has learned to be an expert an 3D animation and video production
Wow. That's awesome! Is any of his work online?
I still remember my favorite professor telling me that she saw things much more clearly at 80 than she did at 70.
Wow. That's awesome! Is any of his work online?
I still remember my favorite professor telling me that she saw things much more clearly at 80 than she did at 70.
I've worked with plenty of snot nosed kids (and not just in software development) who were very quick -- to pull the wrong answer out of their ass. And very slow to critically examine, let along acknowledge their mistake.
Good senior people listen, and if you're right, shrug their shoulders and fix it.
They just ask you to do the same.
One a the greatest pleasures of being on a good "senior" team was that all the members had long since left the superfluous parts of their egos behind.
That team could turn on a dime. And the best part is that we knew when to, and when not to.
TL;DR: Don't fear the beard. ;-)
Good senior people listen, and if you're right, shrug their shoulders and fix it.
They just ask you to do the same.
One a the greatest pleasures of being on a good "senior" team was that all the members had long since left the superfluous parts of their egos behind.
That team could turn on a dime. And the best part is that we knew when to, and when not to.
TL;DR: Don't fear the beard. ;-)
How much do families fit in the with culture of startup? Would it be odd for an employee to have to leave in the middle of the day to pick up sick kids at school? Will you be a "good fit" if sometimes your family responsibilities trump work. What is your desire and inner motivation at 50? It's probably a lot different than the 20yr and 30yr old startup culture. I would say if you are 50 yr old that fits in with the younger culture and have the necessary skills you will do just fine. The reality is though that you are probably at a much different place than the majority of startup employees. You have probably see enough to know how to best spend your time and your priorities are likely different than your peers. The guy doing the hiring knows all of this and where he won't directly use age as a factor in hiring he will take these other factors into consideration. good luck.
If you are 50 years old, your kids are likely to be old enough to get to home by themselves.
Personally I'd hate to work in a place where it would be considered odd to take care of some private business during the day every once in a while. Stretching and leeway goes both ways.
Personally I'd hate to work in a place where it would be considered odd to take care of some private business during the day every once in a while. Stretching and leeway goes both ways.
That's not as true any more. I know a number of couples that "started late" and will be in their fifties just as their kids enter the ~10+ year old age range where after-school activities ramp up yet the kid can't drive. People having kids later is probably going to be another of those slow social changes we'll all have to adjust to.
Divorce happens. People remarry. Many people in their 40s and 50s have toddlers or young kids.
The fit depends on the makeup of the CEO and the management he has chosen.
Regardless, you're going to have to work twice as hard as most of the others in the room. It's easy to walk out the door at 5pm if your work is done. It's not so easy when a crunch is going on and you have an external commitment to make. Nobody likes to look up and see you putting your coat on, believe me.
If the CEO understands, it's one thing. If you have a CEO that says "you need to risk your marriage to make this company succeed" (and yes, I've actually heard this), then you know where you fit in. Unfortunately, you don't learn most of this until you're already in. If you find during interviews that the CEO has kids of his own, that's a good sign.
Regardless, you're going to have to work twice as hard as most of the others in the room. It's easy to walk out the door at 5pm if your work is done. It's not so easy when a crunch is going on and you have an external commitment to make. Nobody likes to look up and see you putting your coat on, believe me.
If the CEO understands, it's one thing. If you have a CEO that says "you need to risk your marriage to make this company succeed" (and yes, I've actually heard this), then you know where you fit in. Unfortunately, you don't learn most of this until you're already in. If you find during interviews that the CEO has kids of his own, that's a good sign.
Would it be odd for an employee to have to leave in the middle of the day to pick up sick kids at school?
Would it be odd for a 20-something employee to leave in the middle of the day to get an oil change for his car, or get a dental cleaning, or have a repairman come to their house?
These are things that probably happen just as often for everyone on your team, regardless of age.
Would it be odd for a 20-something employee to leave in the middle of the day to get an oil change for his car, or get a dental cleaning, or have a repairman come to their house?
These are things that probably happen just as often for everyone on your team, regardless of age.
My though on it, was that there is no doubt that start-ups depend on considerable time investments but even a person with a family can meet them. I personally work at least 60 hours a week and I have 4 kids. I also find plenty of time to spend with them. The difference is, if a employee cannot take some time during the day to deal with an issue because a start-up is in permanent crisis mode, then the start-up most likely has a process problem. There is really no reason that family concerns should inhibit the day to day activities of a start-up. There is also no reason that a start-up should be in a situation where employees are having to dedicate more than 60 hrs a week on a long term basis. If they are you have a bad start-up not a bad employee. People can't run at 70+ for several months on end, no matter there age.
Sure, but here are some prejudices people will have about you going into an interview:
- You don't want to work enough (~80hr/weeks).
- You aren't familiar with new technologies or languages, and aren't curious enough to learn.
- You think slow, and don't have the ability to push stuff out the door quickly.
- You want a senior position as an "architect" or "senior engineer" instead of being an IC like everyone else.
- You want a bigger salary than everyone else.
- It's going to be hard for people to relate to you and communicate with you.
If you can fight against all of those, go for it.
- You don't want to work enough (~80hr/weeks).
- You aren't familiar with new technologies or languages, and aren't curious enough to learn.
- You think slow, and don't have the ability to push stuff out the door quickly.
- You want a senior position as an "architect" or "senior engineer" instead of being an IC like everyone else.
- You want a bigger salary than everyone else.
- It's going to be hard for people to relate to you and communicate with you.
If you can fight against all of those, go for it.
kls doesn't think age discrimination is as bad as it is. I'll wager he doesn't think gender discrimination is as bad as it is either. He's more likely to age than he is to change gender, so we'll check back with him in 30 years.
It's kind of amusing to hear him think of COBOL and Java in the same breath; I've worked extensively with both. Not at the same time, though. :-)
He is on target in saying keeping your skillset fresh is key. Like the Red Queen, it takes all the running you can do to stay in the same place.
It's kind of amusing to hear him think of COBOL and Java in the same breath; I've worked extensively with both. Not at the same time, though. :-)
He is on target in saying keeping your skillset fresh is key. Like the Red Queen, it takes all the running you can do to stay in the same place.
I'm old. I have almost 20 years in the industry.
Yes. I hire excellent people who are interested and interesting that fit into the culture of our company. Age/sex/race/gender/etc. are irrelevant.
We did. Age wasn't a factor in the discussion. If you can play, we want you in the game.
Speaking as a founder, yes I would. I'd also fire one just as quick.
I'm of the mindset that both employers and employees need to be flexible with one another. I may need you to pick up technologies you're not comfortable with and you may need spend your early evenings with your family. I may need you to work 60+ hours on a given week and you may need to work some of that on off hours.
It's a give and take situation with any startup employment. What's objective is what can you deliver and can I obtain a positive ROI from hiring you?
I'm of the mindset that both employers and employees need to be flexible with one another. I may need you to pick up technologies you're not comfortable with and you may need spend your early evenings with your family. I may need you to work 60+ hours on a given week and you may need to work some of that on off hours.
It's a give and take situation with any startup employment. What's objective is what can you deliver and can I obtain a positive ROI from hiring you?
I don't work for a startup but just wanted to comment since I work with a lot of older developers, one who must be well into his sixties is rather interesting as, while he does have his spots where he seems a bit stuck in the past, is constantly trying to inject new technologies into the organization. We're a primarily java shop and he writes a lot of scripts in Ruby and always wants to bring more ruby into projects. I also know he has probably more of a passion for developing software (personal projects) than some of the other developers, who are younger (but still much older than me). I think its really just based on the person. If they really love building software they will keep up at any age because they see the benefit in their own projects.
Age does not matter. Skills matter.
This is interesting. Have to lookup whether startups have already hired 50 plus year old guys?
Maybe phd professors!
Age would matter for a startup beyond just skills. Older hackers might not be able to "keep up" and "fit in" with many startups. Culture fit is really important, but being old doesn't automatically mean no fit.
One interesting thing about a hacker being 50 is that they potentially have an empty nest (no kids), much like their 20s. In some cases they might be able to work "startup hours".
One interesting thing about a hacker being 50 is that they potentially have an empty nest (no kids), much like their 20s. In some cases they might be able to work "startup hours".
i think if you're a 50+ year old tenured professor, your skills are probably not in line with what a start-up needs; you've spent 25+ years of your life optimizing for doing academic research and teaching, not sweating out the details of making product X work seamlessly on platform Y with quirk Z.
some 50+ year old tenured professors co-found companies and serve in advisory roles, but i highly doubt that they're staying up late setting watchpoints in gdb and punching their monitors.
some 50+ year old tenured professors co-found companies and serve in advisory roles, but i highly doubt that they're staying up late setting watchpoints in gdb and punching their monitors.
Companies in general rarely hire older employees exclusively for their technical ability.
The typical 50 year old programmer has worked at numerous organizations, with dozens of teams, using at least as many technologies. This directly contributes to the development of non-technical skills such as communication skills, management skills, insight, and stronger perception. They're rarely oblivious to these skills (as demonstrated by the relatively low numbers of older professionals selling themselves as "programmers").
The typical 50 year old programmer has worked at numerous organizations, with dozens of teams, using at least as many technologies. This directly contributes to the development of non-technical skills such as communication skills, management skills, insight, and stronger perception. They're rarely oblivious to these skills (as demonstrated by the relatively low numbers of older professionals selling themselves as "programmers").
I find this not necessarily true at my company, in fact the oldest people in the engineering department are exclusively developers where the managers tend to be younger or the same age as them. This may depend on region, as well, the area I live in now is rather different than Silicon Valley where I think people wouldn't stick around for years and years as "just a programmer" but in lower-cost, slower-pace areas, I think programming is often just another job to people and its something that people will just continue to do for their entire career.
When I've hired people, while working as an engineering lead at a startup, It's never been about age, it's been about skills + personality. Out of a development team of around 10 people, I'd say 2 were >= 50 years old, a few 30 somethings and the rest around 20-25.
[deleted](1)
some? yes
most? You won't get hired, because you'll be seen as a bad cultural fit for the company.
Only real way to get in as someone that old, is if you are going for the position of a CTO
most? You won't get hired, because you'll be seen as a bad cultural fit for the company.
Only real way to get in as someone that old, is if you are going for the position of a CTO
I wonder how many of the people on this thread who share this opinion have started successful companies.
I don't think that age discrimination is as bad in the industry as people think it is. I think rather sun-setting at some point becomes too much of a draw for most and you also have those that defect to management. I know in my start-up experiences when I was young we used to look up to the older developers that took the effort to stay relevant.
Personally, I would hire someone of any age if they are proficient and have passion to build something. I think there may be some organizations that may look at older developers and think well we can't get 80 hrs a week out of them, but I think they are the minority and I personally would not want to work for an organization that would expect 80hrs a week a standard course.