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.
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...
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.
You sound exactly like the stereotype the original post describes.
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 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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
(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")
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.
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.
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. ;-)
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 :-)
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.
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.
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 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.
- 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.
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 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?
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".
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.
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").
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