When hiring, I was very skeptical of the guy over 40. His CV showed that he had spent most of his time building boring information systems for government agencies. This did not feel cool and startuppy at all. Also, he's gray-haired and he looks a bit dorky. We really liked him in person though, and he seemed to know what he was talking about, so we hired him anyway.

Only a few weeks later, I was already certain that he was the best hire we made up until now. Hypothetically, when forced, I would fire any two other team members to be able to keep him on the team (and he's on only half weeks). He's experienced, very much down to business, he cuts through the crap and through technical fads, and currently ensures that we're building the most lean and simple backend that I've ever seen. In a programming language that he's never seen before, and with a database engine that he's never used before.

For me, the general takeaway was that the wisdom to "not only hire copies of yourself" is very true indeed. More specifically, "older" guys (for tech industry standards) often have a lot more fundamental skills to bring to the table than perfect command of this year's technologie du jour.

Hire older people!

I just did a prototype demo for someone - took about 6 hours - and it was more fully functional than something they'd had a team of people working on for weeks. It's rare that there's that much of a difference, and to be fair there were weeks of communication and discovery going on that I didn't have to deal with. But the other team was also using an older PHP framework which they were painfully not comfortable with (I later found out mandated for bad reasons). Judging by their code, they wouldn't have been comfortable in any framework, but that's another story.

This is far less about how great I am, and more about understanding common problem domains, knowing your tools, knowing when it's OK to cut corners and when not to, and how best to communicate with people. Some of that comes with passion and dedication, but some of it only really comes over time, and the more the better, usually combined with the passion and/or dedication for maximum results.

This is a great anecdote, though I don't fully understand why it surprises people.

Most people in their early 20s are still "kids", both socially and work-experience-wise. Give me a hungry 30+ any day.

It surprises young people. 30+ isn't all that old.

Of course, everything I've done in my life has been late. Graduated college and grad school late, married late, had a kid late. So I'm about 10-15 years behind my age peers and experience-wise have more in common with people in mid-late 30s.

When it comes to having ideas... I feel as though I'm bubbling with ideas these days. Maybe it's just too anecdotal to mean anything, but it seems to me that everyone blossoms in their own good time. There's no such thing as over the hill, until you decide that you're over the hill.

[1] Your profile indicates that you might be based out of Europe.

The problem highlighted by the article is relatively SF-specific indeed, but you see the same vibe in Dutch startups (less so in older tech businesses here, but there it's just that 50 is considered old instead of 40 - the difference isn't that big).

I don't see how that makes the anecdote less strong though. Why wouldn't there be similarly competent 40+ year old people in SF? I feel that startups that are open to hiring older people in a climate like the one described in this article have a competitive advantage on the job market. It makes me anecdote only more applicable to SF, not less.

Personally I've had great respect for the 50+ yr old programmers that've worked on modern teams with me. They've always been great augmentations, and I prefer to hire more experienced people where possible, especially if that experience predates the web.

Outside the valley you find a plenty of really competent programmers mostly in there late 40's along with a few people that are nearing retirement age and while often gruff tend to blow your minds. As in "we stopped testing his code years ago." Or just calling someone team _. As in you could get 15-30 people working on a project or if your lucky Bob.

Theory: This importing of workers has negative effects on age and gender diversity, since it means a higher proportion of jobs go to people who can easily relocate for work. That includes young people (who are less likely to have kids and/or spouses) and men (who more often receive the primary or larger income in a household). I'm sure you can think of other things that are advantages or disadvantages when it comes to moving to California for a job.

There are ways to test whether this effect exists and how large it is. For example, you could compare age and gender diversity across industries. The theory predicts that age/gender imbalance is correlated with geographic concentration of employment growth for each industry. You could also see whether these imbalances are worse within industry hubs, compared to companies in the same industry outside the hubs. (Though the effect can also spread outside the hubs if it influences a culture that gets exported to the rest of the industry.)

I'll bet geographers or sociologists have published research on this subject, though I don't know enough to search for it effectively. (I found some vaguely related papers on Google Scholar, but nothing yet with data that would directly answer these questions.) There are some historical parallels of course, like gold rushes and resource extraction booms that cause new industries to grow suddenly in a particular area.

The need for developers is so strong that all the major tech companies are devoting resources to recruiting as soon as developers graduate.

That dynamic could account for a reasonably large part of the age imbalance in the industry. If there was a similar-sized pipeline of recently-trained developers with a more diverse age group than university students the story would likely be different.

You will see the following in experienced, good consultants as well. A lot will go wrong on a gig that is not anticipated during the initial scoping of the project. The inexperienced (often but not always correlated with youth) will "freak out". Whether it is a passive flip out like analysis paralysis or a more overt one, the end effect upon management/clients is still unpleasant for them.

Even when I was much younger in the field, I observed some of the older staff tended to have an imperturbability and unflappability about them even when presented with unexpected and unwelcome challenges (read: emergencies). They often didn't know what the solution was, but had enough taste and experience to know where to start and to start Getting Shit Done. This meant picking a likely direction of troubleshooting and just start walking a breadth-first search of causes, then a depth-first on anything turning up from the breadth-first that looked promising. Easy to describe in these antiseptic terms and comfort of your keyboard, hard for many younger developers in the heat of the moment when there is a frantic manager beating them about the ears that the company is about to go under if they don't fix this "right this damned second!".

This points out another observation I've made about managing younger developers. Do not mistake their energy level and enthusiasm for the degree of emotional and verbal abuse it requires to engage them. It might be different for other industries and positions (I doubt it), but too many times I've seen people take the easy way out and subscribe to the Management by Berating school. Also called the Management by Complaining/Screaming/Browbeating school. You can mention the dire effects some emergency has to the younger crowd to establish context, but move on from it and don't use it as a way to urge them on to fix something faster. Most younger developers simply do not possess the life experience to easily tamp down the anxieties they feel and set them aside long enough to dispassionately fix the problem at hand if there is management at their desk anxiously wanting blow-by-blow updates.

This doesn't mean you simply dump the problem in the younger developers' laps and walk away, either. Neither extreme is good for your team or organization. Lead by example with a calm approach to working the problem, either make decisions on where to start or support your senior leads with their educated guesses with where to start (and if you don't know where to start and don't have senior leads to turn to, you've got bigger problems), triage the effects with mitigation tasks, assign bite-sized tasks to the less experienced developers as your judgement advises, create a big picture view for yourself with the best information available of where your team stands with the problem, clarify the picture as you go along, and run interference from the rest of the organization's managers who Manage by Dysfunction.

A side note for younger developers. The only partial shortcut to that unflappability I've had experience with is to secure yourself 2-3 years of living expenses as soon as you can. It helps you achieve perspective, especially when a manager yells you'll lose your job over something. It isn't a replacement for experience, taste, judgement, whatever you want to call it, but it does help a lot with compartmentalizing the emotional component of facing down stressful situations at work, which takes most employees a decade or two to learn, and some don't learn it at all.

Are you sure you are not committing the same ageist judgement here?

One is an active reverse discrimination that is attempting to tilt the balance back (often enforced with some kind of law or policy). This has all kinds of well-known problems (that arguably are larger than the benefits).

The other is a more natural reverse discrimination that comes from collecting the missed opportunities of your competitors. If your competitors reject candidates for frivolous reasons, then it's easier for you to hire qualified people. I think this is what the parent comment was doing, and it doesn't strike me as a problem.

The tooling accessible to people today as opposed to those that started 10 years prior is also extremely different. Running Windows? Trumpet Winsock, understanding the win.ini, config.sys, and autoexec.bat were important. Linux - a lot of people have wasted a lot of time getting sound and video drivers (as well as xf86config files) to work right, most just work fine now. All these required a level of digging that required knowing more about the system than you may have wanted.

Not saying your point isn't valid, but it does depend on what one's definition of "competent" is.

Prove it with some research. The current research shows that people really don't make their best contributions to their field before 35-45.

And, to be fair, I see more young people who attempt to hit the screw with a hammer because a hammer is the only tool they have.

Look at someone like John Carmack - before he was 35 he had done Command Keen, Wolfenstein 3D, Doom, Quake 1-3. Guys like Steve Wozniak were basically out of the business by the time they hit 35. Linus released Linux when he was 22, and started git when he was 35. I doubt guys like Marc Andreesen have written much code since they hit 35 as well.

So, basically what you're saying is that young people can churn out software where you can undo your huge screwup, but if you have to get it right the first time like hardware, then you need some experience.

You are the one with a "platonic causation", namely, older = rigid thinking.

Enders Game is a child's book, written to appeal to children. Note we don't actually have 9 year olds making decisions in reality.

What you're saying is that some people don't learn from their experiences. You should focus on finding out if they have. That's worth way more than hoping that this young kid will.

Good developers do use pattern matching. But good developers just use it as a way to come up with ideas, and they use their experience to judge the ideas.

There's no such thing as "bad experience", just poor reasoning skills. And mostly people will improve their reasoning skills over time. Unfortunately, not always.

There was lots of stuff going on with the DEC minicomputers, LISP machines, early UNIX systems, and big-iron mainframes long before most of us were even born, let alone getting our starts on TI-99s, Apple IIs, and Commodore 64s. And let's not forget that the people who were creating those early home-computer platforms were themselves all from the previous generation.

Would you turn people like Steve Wozniak or Al Alcorn or Ken Williams away from your new startup? You'd be a fool if you did. The basic architecture of computers hasn't changed at all since they did their most important work, and the cognitive skillset that makes a great programmer is the same as it's always been.

In fact, I'd expect that people who cut their teeth on early systems, and had to work within narrow constraints, without a big stack of abstraction layers and frameworks, would be all the more adept at writing robust and efficient code than those who learned on modern tools. And I'd bet, with Moore's law slowing down, and with better-optimized code becoming more advantageous in building scalable systems, older programmers will soon be in higher demand.

(Not trying to short-change Bartik here either -- she did a lot of the work on the ENIAC instruction set when they converted it to a stored-program computer)

Edit: And many more "giants", of course…

I think that it would be a mistake to say that computer science has truly been around for 160 years, though. A few people (there was also an Italian who was interested in Babbage's work, although I'm not sure what his contributions ended up being, if any) does not a field make, and the fact that any progress in it was more or less put on hold until the early 20th century (when mathematicians started working on what you could calculate or construct in a finite number of steps), and you didn't get (untyped) lambda calculus and turing machines until 1936, which is probably the best place to truly start the idea of computer science as a field. (And since you got early devices that were sort of primitive mechanical computers in the late 30s, early 40s as part of the whole Bletchley Park cryptography work by the Brits.)

A very large debate around the turn of the century was if mathematics that you couldn't specifically construct in a finite (or countable) manner were, which became particularly heated after Cantor's set theory work (showing that the real numbers were uncountable) and then things like Russel's paradox (showing contradictions in Cantor's naive set theory if you allowed sets that contained themselves). I'd argue (without firm, researched proof that it was definitely the intent and case) that the spirit of early computer science (lambda calculus, turing machines, etc.), which was concerned with what you could and could not compute with a finite algorithm, came in spirit from those sorts of debates. (See finitism, intuitionism, constructivism, etc. for parts of this debate; traces of it remain in modern day mathematics with some people's concerns about if the Axiom of Choice is a valid or reasonable axiom to have)

ENIAC was ininitially put to work calculating artillery trajectories, once the programmers figured out the bug where the shell kept going after it hit the ground (oops!).

I started programming toys in 1979. [1] I started programming "modern" computers in 1981. I was selling games when I was 15 in 1983. My "real" professional experience started in 1987 with a contract to write a video game from a major publisher.

So yes, it's not hard for someone to have "more experience" than you in general programming.

[1] I had one of these: https://en.wikipedia.org/wiki/Big_Trak

http://www.bigtrakxtr.co.uk/home

Do you know how many people were doing that? you are way over estimating the amount of people in the world with your experience.

You said "No way a 40 year old guy have more experience than me". To disprove an absolute statement you only need one example.

That said, a significant fraction of my friends from those days were doing similar things. I won't deny that I'm particularly good at programming, but all of those friends could also claim more experience than you.

I've heard a number of these comments recently drastically underestimating how long computers have been around.

> No way a 40 year old guy have more experience than me in general programming, unless he was working at Microsoft or IBM at that date, and surely they are about less than 10000 of those guys in the world.

You're talking about 1989, right? In 1983, there were 443,000 computer programmers and 276,000 "Computer systems analysts, scientists" in the United States alone (source: http://www.census.gov/prod/2/gen/96statab/labor.pdf).

I'd be really interested as to how you get that figure...

If you were using one at age 10 and are now 35 that would have been 1989/1990 or so... there were no magazines writing about it by that time. You had some old issues of the TI-99er or something?

So it makes little sense to suggest that it's somehow a crazy idea that someone 5-15 years older than you (in their 40s) might have a longer track record working with computers.

Working in a bank, not for an editor...

FWIW, I'm 47 and was programming assembly and microcode in my youth. So I have 10 years on you. At this scale, I doubt the difference matters much. Because you are old, too.

Also, you have about 30% more experience than me, I don't think it's a small amount.

1) Older programmers won't put up with bullshit. They expect to have reasonable goals, be listened to, be compensated fairly, and have a reasonable schedule. They've been around the block enough to identify bullshit and will leave when it starts getting too high.

2) Older programmers really don't always understand the "cool" social crap that teenagers are into this year (for good reason--most of it is garbage). Unfortunately, most of what Silicon Valley is interested in is "cool" social crap so that they can get a big buzz and flip the company to Google or Facebook.

Funnily enough, companies that value that silly thing known as "profit" are quite happy to hire older programmers. It's just a function of Silicon Valley not believing in profit that is causing the ageism.

It seems everyone these days is a "founder" of something. I own sites that do things these youngsters can't do (Turn a profit) but I've never, not for one moment ever thought I was a founder of something great, just trying to earn a living!

I agree with the companies that believe in profit thing. Once you strip out the happy clappy, social crud employers just want people who can help them turn a profit.

I do agree that I am way more experienced, knowledgeable, and have a much more healthy and mature perspective on business and software engineering than I did when I was 22.

You are a year or two from being 'old' in this mad market.

Is there a list of companies which value profit so the people who complain about the "problem" (from companies most likely to not be around after too long) can go work for them?

It would certainly match up with my experience in London, where it seemed that a lot of the programmers over the age of 30 were working for large, established finance companies. The age of programmers around the 'Silicon Roundabout' startups tends to skew a lot closer to mid 20s.

This derails in reality because you'll have companies making money but bullshitting their employees to save most of it. You don't need the best of the best programmers to have a shippable product, and even if such a company is only mildly profitable, keeping the profits at the top makes it a good place for stake holders.

http://directory.thesmallbusinessweb.com

My father got lucky in that he was successful in his transition out of engineering, and was 67 by the time his position went extinct, but there are a whole bunch of folks who would rather have been engineers than otherwise, but ended up missing out on a couple decades where the daily tasks of building software changed dramatically so gained less in technical expertise than they should have, and were left hanging around age 50.

I have a ton of cultural criticisms of the current tech industry, but the one thing that it is absolutely getting right is valuing creation. The damage that could have been caused by the Google/Apple cartel has been limited largely by the startup industry that, for all its faults, has as a crucial belief that the act of building things is valuable, and that people who make things are the ones who create the most value.

I remark to folks all the time that you can take someone right out of high school, and have them spend about 2000 hrs learning about "computers" and now they are 'hot shot programmers' that are in demand. 2000 hours is a bit more than a year at 5 hours a day factor in that the math, and intro classes aren't necessary for someone who has both done the degree before and spent some years working in the field, and I suspect that any engineer taking a 6 month sabbatical could be right back to current. And completely current with the wisdom of organizational dynamics, work habits honed by years of what worked and what didn't, that person should be like gold.

The place where I feel sad is when someone says "I've been unemployed and spent the last 6 months sending out resumes and no one will call me because I'm old." Had they instead spent that six months re-tuning old talents, sending out the occasional resume, and building stuff, that seems to get people hired regardless of age.

There are two problems with that logic. The first is if you have only six months of experience doing something your pay is likely to reflect that.

Second, look at it from an employer's perspective. You can hire a twenty year old or a fifty year old. They have the same experience with whatever the latest thing is. The twenty year old has the energy of youth. No wife or children. He may come in hungover occasionally but with enough Red Bull he'll bounce back by noon.

The fifty year old is slowing down. He takes drugs for his blood pressure that make him tired. He has ailing parents and teenagers at home.

Who do you think is going to be more productive? Who's going to put in 16 hour days at crunch time?

You can't play to a young man's strengths if you want to compete with young men when you're over forty. IMO you'd be better off as the last guy who knows COBOL than just like every other mobile programmer with six months of experience except older and slower.

    > The first is if you have only six months of experience
      doing something your pay is likely to reflect that.

   >  You can hire a twenty year old or a fifty year old.   
      They have the same experience with whatever the 
      latest thing is. The twenty year old has the energy 
      of youth. No wife or children. He may come in 
      hungover occasionally but with enough Red Bull 
      he'll bounce back by noon.

   > Who do you think is going to be more productive?
     Who's going to put in 16 hour days at crunch time?

But if you assume work performance based on age, gender, race, religion, or sexual orientation, you will always be doing it wrong.

I could have probably done it, but really only 6-9 hours a day, like you say, would have been actually working on what they were paying me to work on. I'm still not sure how a schedule like that could ever have been considered sustainable for anyone who wants to have any of: a social life, family, or professional development time (going to meetups and such).

And? What is this article about? Do you think it's productive for older guys to cry about age discrimination when they can't find a job? All I'm saying is you play to your strengths when you're looking for a job, no matter what your situation is. And being an older guy with just a handful of years in a brand new technology is playing to your competition's strengths.

Companies that wouldn't hire an older guy as an Android programmer for $35/hr will shell out $300/hr for that same guy to teach an in-house six sigma class for two weeks. So be the six sigma guy. Does it make sense? No. Does that matter? Again, no.

>But if you assume work performance based on age, gender, race, religion, or sexual orientation, you will always be doing it wrong.

That's all very nice and totally irrelevant when you're the one looking for a job instead of the one doing the hiring.

This assumption is wrong. They don't have the same experience. Their direct experience (counted as the time they spent hacking with the latest thing) might be exactly the same, but this doesn't translate to the same effective experience / capability. When I was 20, it took me much longer to become productive with any new thing than it is now when I'm 30. A 20-year old with a 6-month experience with a new language would struggle a lot even with basic concepts. A 30 (or better 40) year old, who already knows 10 other languages and a ton of frameworks would pick it up in single days or weeks and became productive very fast, leaving him much more time to dig into the advanced concepts.

When I was about 18 years old, I struggled hard with a math proof related to number theory a teacher gave me. I never solved it then when I was at school and soon moved on to some other things. Recently, when on vacation I recalled that puzzle and started thinking about it just for fun. I solved it in a few minutes by just drawing with a stick on the sand. I never studied theoretical maths nor dealt with it professionally, so I had no direct experience in doing math proofs. Somehow, my capability now is much better than it was 10 years ago. I call it "indirect experience".

I'm 31 years old, have been doing lots of crunch times of 16 hour days that lasted for weeks and I really hate this expectation and mentality.

I'm more productive than ever, even though I started saying NO to overtime, because fuck you. Yet, I've worked with plenty of beginners and when I say beginners, I'm talking about 5+ years of experience and I have been more productive then all of them, even though they've been more eager than me to work overtime.

The difference has been in the following areas:

1. less experienced engineers when facing a hard problem tend to slap some code in place that barely does what the feature request asks for, without thinking of the implications much, like the potential for accidental errors, or how that code interacts with the business logic already in place, or how that functionality will interact with future features already planned. And so every sprint, every release you end up reworking/rewriting/fixing stuff from previous releases, because a rookie skipped the due diligence and slapped a poorly thought out turd. As a consequence, that's why we have software development methodologies, like Scrum, or whatever agile bullshit is the latest fad, because process is required to get good results with average people.

2. no man can keep focusing for more than 7 hours per day on average. Yes, I've been able to stay "in the zone" for more than 12 hours occasionally, however the average for really good people is no more than 7 hours. The rest of the time is filled with "busy work", like pointless meetings, replying to email, reading HN and staring at the monitor stupidly. If you don't believe me, install RescueTime and marvel at the huge amounts of daily jerking off.

3. Solid work requires a well rested mind. I'm at the top of my game when I sleep well at night and I get great ideas in the periods in which I have a good social life.

4. I learn faster than any 20-something, because I have a solid knowledge base. For example it takes me about 2 weeks to become functional in any programming language, that's because I've already worked in production and played with about a dozen thus far and in regards to paradigms, I've already worked with them all.

> No wife or children.

5. Pity that you view that as a liability. As a father of a 4-year old boy, I can tell you, a child is the greatest motivation you could ever have, which is why I trust people with children at home more than I trust a 20-something that hasn't felt what true responsibility is like.

* bad_user would be based "anywhere outside of Silicon Valley".

* You wouldn't be.

I was right. (bad_user is in Romania, according to his LinkedIn.)

That's not to say it's easy to blow off demands of overtime outside of Silicon Valley either (I've heard horror stories about game companies), but the tech companies that you can do it at seem much more common.

It may simply be founder/executive age. When the CEO has to go coach Little League, he loses any moral high ground he had for saying you can't go play with your kids.

Being able to say NO is not a matter of where you work, but rather one of actually saying NO. It may not work well of course, your managers and peers might not like that, the secret being to not be at the bottom of the chain - as in, you have to be reliable and capable and work on hard enough problems as to not be easily replaceable. If you can prove that you're as good or even better than somebody doing overwork (which is entirely possible because of the reasons I outlined), then nobody will mind, as in the end it's all about the value / artifacts produced, not about the lines of code written and not about the number of hours worked.

And in my oppinion, if you can't produce value while working regular hours, then working overtime won't help anyway. And if you can't produce value with overtime, do you think your boss will keep you hired just because you're a "hard worker"? The market really doesn't care about that and your boss/manager would be an incompetent if he thinks otherwise.

Speaking of market forces, it's a mistery to me how you Sillicon Valley based developers, that live at the horse's mouth so to speak, can't easily switch to jobs that you like in case you're working in environments full of jerks. I mean, even if everybody expects you to work overtime or to do things you don't like, you can always build your own startup for Christ's sake, something that I (being outside of the US) can't easily do.

That's been my experience. Companies will push and push until you say no. After that they may not give you 30% raises every year, but they're not going to fire a productive employee who refuses to put in long hours.

But that's just my personal experience.

On Saturday, of course, things wouldn't go as expected. Many times we were still there at midnight, and he came around asking us to stay for just one more hour so we could help test the latest build. Then there were more problems, so he'd ask us to come in on Sunday. For just a half day.

This happened probably three weekends out of four the first year I was there. It got to the point people were taking Friday off because they figured each hour of vacation was actually worth three hours.

So I came to the realization it was either put my foot down or find another job, so one Friday I went into his office and said "Don't even ask me to come in on a weekend. Ever again." I thought it might cost me my job, but that was the end of it.

That has all changed and yet back then was accepted standards from what I could tell. More a insight into culture change but I have not heard of any agisim culture inside IBM before or now, just a beard thing, which has passed.

With that anybody have any insight as to any agisim aspects inside IBM past or present?

IBM used to invest in it's employees. My advisor was of a generation where if you saved IBM X dollars in terms of research patents, etc, you were well supported as time went on. Additionally, they had a culture of investing in their employees. I don't know when the change happened... I want to say sometime in the mid/late 90s things shifted and have since.

That said, most of the new hires were under 25, and most of the older people had been employees since the age of 25. But definitely the older people got all the respect.

IBM's full time offer to me was a solid 1/2 of Google's offer after stock and bonuses (over 2 years), with no room for negotiation.

What's wrong with that?

We were essentially doing the lose-lose algorithm. It's a functioning hash table but there's a lot of room for improvement.

There was a cultural shift internally when Gerstner was brought in - before then, there was a culture of "join us, and IBM will take care of you". Saving the company in the '80s required giving that mentality up, and it destroyed much of what, in my parents' eyes, made IBM a special place to work.

For development, it's all about having your niche. If your niche is stable, age isn't an issue. If your niche is going away, there's little reason to keep a 50 yr old C cubicle guy to switch to consulting, 50% travel and code the latest flavor. There's just no cruising on your laurels anywhere anymore and the market turns over much more quickly.

My observation of recent layoffs is that it's ageism in that most of the people in these jobs are well into their 50's and some into their 60's. Young is 40, and if you weren't in a critical niche, you were just as likely to go as any.

There are still some colleagues my age who still wax about the days of writing JCL for their mainframe jobs and never evolved past the 80's and perhaps they gave a bad name for others who built on their of years of experience with evolving knowledge.

I decided in 2009 to specialize in mobile, when I realized how impossible it was for the startup I was working for to find any high throughput engineers, let alone high throughput engineers with niche expertise in mobile. I think it is an advantage in some ways during interviews that I can talk about decades of awesome projects I worked on while also being among the first to ship an iPhone app or a top ranking iPad app.

As they say, luck is when preparation meets opportunity. It's my job to make myself lucky.

As I get older, I find that is easier said than done. I still spend quite a lot of time learning new things, but I've become less interested in learning things that are immediately marketable. Learning yet another framework that is marginally different than the one I used on the last project is not the interesting pursuit it once was. At this point I would rather invest that time in something that might fundamentally change my outlook and understanding of the world, which is beneficial in a meta way, but isn't really something that you can specifically write down on a resume.

I find the older I get, the slower I produce code. I spend more time thinking about the solution than coding the solution. This tends to frustrate my employers, who follow the "move fast and break things" philosophy. They think I shouldn't have to think about it, just do it.

So, I guess what I'm asking is, in your opinion, is my slowing down a problem? Or an advantage?

If it's incurring a similar bug load and just gets done slower, that's a problem and they're right to be upset.

I've seen both cases before, even from very experienced people, so it's very specific to the situation.

Freelancing might suite someone like you very well though. The best freelancers write solid software at the pace that works for them.

sorry, what? any team that thinks "rapid development" actually means writing code more quickly is a team composed of idiots - I think I must be misunderstanding you?

We're just figuring out where the old abstractions land and the syntactic sugar has made life easier.

There is a massive personality issue at play. If you love this stuff, you don't let new stuff pass you by and end up being a specialist on the dead end. You're constantly sharpening the sword... because you love sharpening swords. Staying relevant and employable is a side-effect.

I also think I wrote kind of silly code then. I always laugh when I think about a persistent hash table I had to write and how I went out of my way to find prime numbers for M slots using Fermat's Simple Theorem (not his last theorem) and testing for Carmichael numbers. Of course, there aren't that many prime numbers in the first place and a static table would have worked just fine! I always remember this as part of my evolution from an inexperienced academic kid solving a problem that doesn't need solving vs. experience to know where to comprimise and just get it done.

Even then, I knew it was important to start specializing where the needs were evolving, which was win32 programming at the time and eventually Windows MFC programming. This all dove-tailed nicely years later when I started working on the Playstation 3, where you develop in MS DevStudio but the PS3 was essentially a Unix box. It's funny how things work out.

The only thing that sucks about being a 40+ engineer is when I say "whachoo talkin' bout Willis" or "it's tricky to rock a rhyme", half the people don't know what I'm talking about.

There's your problem. You have to ask it as a question.

Try telling someone they're "2 legit 2 quit"; the kids today are not sure if that's good or bad.

Interesting! Was it ageism or was it because you were inexperienced? This is tricky because I feel like even if younger developers are discriminated against based on their age, they might be less likely to attribute it to ageism. If this is true then I wonder if older developers are for some reason more likely to blame ageism for their career ills instead of skill obsolescence, hence making ageism seem like something that mostly affects the older devs...

Agreed! as discussed here: https://news.ycombinator.com/item?id=7452643

But I think it's also easy to see it as an opportunity. We are staggeringly lucky generation; software is the future and it isn't going the way of mass automation or obsolescence any time soon. There is probably another two hundred years of foundational innovation left in the field, we're still just scratching the surface of information theory and what's possible. Experience is likely to increase in value.

As individuals; by cultivating just a little higher order thinking, and seeing above the surface layer of raw code, it shouldn't be hard to offer meaningful value and insight for the remainder of one's lifetime. I don't think the key is learning to "adapt", progressing from one fad language or technique to another, so much as it is to see the similarities between these fads and to understand them at a higher level of abstraction. To understand that SOA programming is the same thing as micro-kernels, or CSP, for example, and to seem to offer new wisdom by regurgitating the old.

In that spirit, I've observed that the successful senior engineers I've come to know don't decry constant change, but constant same-ness.

People are talking about this a lot in the context of women too - is this "cultural fit" expectation keeping women out of the profession?

I think women in general are equally able to hang and be a bro, but in some cases it means they need to adapt, and some women are resistant to operating in a masculine space.

Back then old meant something different as it was a new industry, older people didn't grow up with tech and there was a huge valley/difference between someone that gets tech and a generations before that didn't have it. Everyone below 40-50ish (and definitely everyone in their 30s and below) has had tech around their whole lives and at a more core level as it was new and attracted mainly young people then, but now it attracts all people and has had people working in it for decades (past mid 90s when the internet went mainstream, most are still doing it).

I have to say working for over a decade in tech/programming that most of the really good programmers were over 30s (and all good product developers were either close or over 30), this is because it takes 10 years to get good at anything even if you start in your teens, shipping products for 10 years can't be sped up. Someone out of college at 23-24 needs to work until 33-34 to be really good. To discard that is futile and young programmers might even be scared away from this line of work if there are no future prospects. I also believe it will be detrimental to our entire country as technology is so important now.

Funny enough in game development some of the best I have worked with were actually in their 40s nearing 50s even though it is also seen as a young industry, game companies wouldn't ship anything without experienced developers of 5-10 years, you can't get that experience and then be worthless at 35.

When there is a new industry, the people in it at that time sometimes gain more valuable lower level experience because the platforms/layer is still being constructed. So engine developers that are older were almost always better than younger because they have the core knowledge without the layers of fluff that product cycles can add. Just like back in the day hardware was more prevalent and a population of people that were in it then are sometimes better at it because they were around when it was big.

The market is also solving ageism by paying programmers better than managers many times. Noone will desire to go manage if it is a step down. There was a temporary moment in time when there were NO development managers, sales/marketing/bizdev couldn't manage it. So they NEEDED programmers to go into management to make sense of it and they are good at marketing so it stuck in the collective psyche. That has changed dramatically and I believe this will mature the industry.

Also, let's not confuse ageism for VC funding selectiveness, they will always choose younger because the term sheet is easier with younger that are less knowledgable about value. The 'problem' with older coders is they know they can ship and know their value.

Who knows, if the WhatsApp guys were younger Facebook could have gotten it cheaper. If older developers build more value, VCs will see they can flip for higher amounts and that may also help this perception problem.

Ageism isn't just a problem for older developers, it is a problem for younger developers as well in that they are smart contributors that will be shut off after 10-15 years of solid work, right when most of them will be in their prime and contributing to society.

Now I'm in the Bay Area and I often consider getting out but in general the jobs here just have better benefits. I'm not just talking about foosball/ping pong tables. I'm talking Gourmet meals, 3-4 weeks vacation, unlimited sick time, people who want to work on interesting technology problems, great salaries plus equity.

If I decided to leave my job today, there are a ton of good options all over with the exact same comp package, because they have to to be competitive in this area. I could relocate but I'd feel I was held hostage by the other options in the area I chose to move to.

I've seen the other side and it'd take a lot for me to go back.

Edit: I know not all of Silicon Valley is doing pointless startups.

But there are a ton of startups/developers building really cool tech - in SF and beyond - and they end to be older and more interested in real technology vs cashing out their options.

The bootstrapped, 6-year-old former startup I work for is filled with people from their 20s on up past 50s making, selling, and supporting Software as a Service, with the developers hacking away at a RESTful API and Ember.js apps. Plus, we share the building with Kickstarted startups like Pixel Press, VC-funded startups like TrakBill, etc. and we're a couple blocks from an incubator + coworking space with 80 startups at every stage.

Being away from Silicon Valley doesn't make you automatically boring, or a cubicle farm, or even full of old people

"RESTful API", "Ember.js apps", "Software as a Service", "sharing the building with kickstarted start ups".

As an iOS dev here, you can expect to make 85-100k and spend < $1000 / mo on rent. There's also no state income tax, so you get a 9.6% bonus right off the bat. Not too bad if you ask me!

Take two 50 year old engineers. The one who has had 10 jobs over the past 25 years is considered infinitely more employable than the one with 25 years at the same department of the same company.

This case isn't ageism, it's the expectation of career stagnation, yet many of those engineers with that 25 year tenure think it is. It's a leftover from the days when loyalty was tied to tenure, and loyalty was valued highly in the hiring criteria. Those days are over. Loyalty is nice, but loyalty that negatively impacts your career options (no learning or improving, inability to use marketable tech skills, etc) is foolish.

When you say 'people like me', keep in mind that just because you have had three different roles at one company in itself doesn't mean you didn't stagnate, just as the person with ten jobs may have stagnated.

All assumptions have some danger, and I'm not condoning the behavior. I think it's valuable to explain to people who feel they are being discriminated against based on age may be more likely associated with stagnation (actual or assumed) based on extended tenure.

I'm certainly not saying that someone who has held multiple positions has not stagnated, either, simply that fundamentally the only difference between me and someone who worked for three different companies but had the same roles as I did is merely the company nameplate. To make different assumptions based solely on that is illogical.

Are you arguing that in that scenario it's more likely that the one-workplace worker really has better experience, or are you arguing that it's possible that he has better experience?

CV-sorting is not a maximization problem, it's a satisficing problem of getting a few good candidates to the interviews at a reasonable cost; which generally requires throwing out 90% of CVs without spending the resources to seriously investigate those people. As long as you have enough qualified candidates, factors that "often are bad, but sometimes are good" equal an automatic forward to the circular folder under HR desk.

[1] As we all know, all greybeards use Lisp ;)

What's the distribution of software engineers by decade across a 40-year range? Is anyone here willing to argue that it's completely flat? Of course not, there are far more SWEs in their 20's than in their 60's.

I have never once had my age be an issue at work or in an interview. My resume clearly states my work experience, and goes back 20 years. I don't have to hide anything, and I don't expect I ever will. Am I willing to believe there are employers out there who try to discriminate by age? Of course there are, just like there are fraudulent companies you could work for, sexist assholes you could work for, etc.

None of these matter because you don't have to work for these people. As a competent engineer your skills are in demand, and you get to pick where you'd like to work. If you aren't a competent engineer, no amount of plastic surgery will get you hired, and please stop using your age as an excuse.

We look at engineer hiring to determine what's valuable, and what's teachable. Do we want our engineers to be current? Yes, but only reasonably so. Anyone who has been around long enough will recognize that most currently popular technologies in use as tools of the trade are simply iterations on ideas that have existed for a long time. Any individual who thinks we're in the dawn of some amazing age where the tools are only understood by a certain generation is, for lack of a better word, foolish.

So, for us being current is really just status at a point-in-time. It's entirely teachable (or better yet, learnable.) But what's valuable? Understanding your trade is important to us, but having real experiences under your belt is super-critical.

Have you ever run a large-scale operation where your code was mission-critical? That's important to us. Ever been responsible for deployment that required zero downtime? That's important. Ever had to ship code and the difference between success and failure meant revenue and jobs? That's important. Ever actually done more than one thing besides {web/mobile/admin/etc.}? That's important.

So, we try to combat ageism by ensuring we give young folks a chance. Not everyone gets that opportunity, but we do so sparingly when we feel such an investment is worth our time, money and effort.

It's also a natural progression of an engineer to start off as an employee & then take an independent identity. So it's common to see older engineers become consultants & business owners; who then hire the younger, cheaper, more impressionable employees.

I see an old/young tradeoff between pattern recognition and fluid intelligence.

Maybe why some older developers show less enthusiasm for the next really "awesome" idea is that is really isn't that new. Maybe the older developer has already learned the hard way the downside of the Dunning-Kruger affect, where: the more you know, the more you know what you don't know.

On the other side of the coin, maybe older developers have a blind spot towards opportunities that have failed in the past. Because the timing wasn't right. Because the audience wasn't ready or the infrastructure was premature. The secret of a good joke (and startups) is timing.

Perhaps some startups are best structured like a team sport; with both younger players at the peak of their brilliance and with older players that can both play and coach.

Yes. A lot of things have to come together for something to work. Something can fail many times before succeeding. A little irrational optimism can be a good thing. Hitting the ground running at the exact moment is very challenging.

Take your average 20 something year old hot shot highly sought after programmer, well I make 3 times as much as him. As soon as that little tidbit of information is out of the bag, I'm suddenly "too old" or would not be "good cultural fit" for the budding startup.

Sad thing is, it's true. Most of the companies these days are not really solving hard core problems any more and don't really need someone of my level of expertise and skills (how many are in the guts of an OS, databasse or compiler, or need their server performance insanely tight). Most are hoping to disrupt Facebook or Twitter, and for that "social" stuff kids who don't know what they are worth are better suited anyway.

(1) If someone doesn't keep up with currently relevant technology, they will find themselves without the job skills that employers are looking for, regardless of whatever other qualities they may have. This isn't ageism.

(2) If someone works at the same place for 10+ years, getting raises every year and becoming more and more valuable because of their knowledge of the innards of one or more huge codebases that are specific to that company, they're likely to have a hard time finding another job doing something different that pays as much or more. It's very easy for people to settle into a routine for many years that doesn't necessarily carry over to another job. Someone in this situation might have to take a pay cut (maybe a big one) to start from square one doing something else at another company. This is an unfortunate reality of being a software developer, but it also isn't ageism.

(3) If a really young entrepreneur is hiring for their startup, and they haven't had the life experience to develop the maturity and insight to avoid being biased towards hiring people who are just like them, it is possible that they will favor a younger developer over an older developer based on age alone. They may not even be aware that they're doing it, they might just feel like all other things being equal, the younger developer is a better fit for the company. This could be ageism sometimes, and it's very unfortunate when it is.

(1) and (2) are the perils of having a long career as a developer. Employers who don't hire someone because of these reasons are making rational hiring decisions; they're not making decisions based on being biased against someone because of their age.

I don't know how often (3) happens though. I could see it being a problem in SF, where I've heard the job market is disproportionately composed of startups. I don't think it's like that in the South Bay (at least not to the same degree), where there are tons of large and established companies that are less likely to do this.

Except.... I do see younger people getting hired who don't necessarily keep up with current technology. It may just be that they're ultimately cheaper, and it's just financial. But I do suspect that older devs are held to a higher standard on this front ("what? you're still using Rails 3? luddite!")

It's not necessarily rational unless the company holds all candidates to the same standards ("current with technology", for example).

My next job likely will not be using this software so I'm doing my best to keep up with what's changing in IT generally. I even schedule a time once per week to work on a side project just to make sure my development skills stay sharp-ish. Despite the effort I put in, I expect that I'll likely have to take a pay cut if (when) I go to another job at a different company.

If it sounds like I'm complaining, I'm actually not. This is just how it works I guess.

I'm also not surprised that investors are biased. As a group, they are just people with money. That feature doesn't preclude them from being unreasonable in the way (one would hope) being an engineer implies a certain level of objective rationality...

What does surprise me is the fear that is apparently spreading among aging engineers. You didn't get where you are by being afraid. Every problem you've ever solved proves your ability to bend systems to your will. You design your own fate. Don't make yourself vulnerable by believing anything else.

</rant>

On a more practical note, if college students had more opportunity to team up with older professionals on small co-owned projects, I think that would go a long way toward bridging the gap. Exposure is key. That's like, behavior therapy 101.

We have a massive age range all the way from 20 to 60 (I guess), with most of the better engineers in their 30s-40s it seems, though to be honest you wouldn't really know unless you asked - there are guys here that you wouldn't guess were 40.

Personally I know I'm a far better engineer now in my mid-30s than I was in my 20s and to be honest I STILL feel like a beginner excited to finally find his feet. I don't see this stopping anytime soon. I don't want to get into management and luckily don't have to and I'm sure at 45 I'll be a far better software engineer than I am now (well, I sure hope so at least :) ).

The people in SF/SV building apps are mostly in their 20s-30s.

The people building cool technology are mostly in their 40s-50s.

|The authors examined the high points of the careers of both great inventors and Nobel-Prize winning scientists, and they found that the late 30s were the sweet spot for strokes of genius

The gist is that this number (38ish) has been slowly creeping up over the past century; it is generally higher in those fields which require a synthesis of huge amounts of knowledge (experimentalists) and earlier among theorists. Notice that essentially no one has done anything groundbreaking in their 50s (yet).

I know 20 year olds making brain wave analysis breakthroughs and 50 year olds making poker apps. And the reverse.

Great work knows no age.

And there's not enough of it to go around.

Besides, I write my best code when I'm jogging. I just type it in when I get back to my desk.

You have to play close attention to the incentive structure of the business. The situation is arguably worse for startups if you're salaried: you're 'changing the world' so it becomes OK for the occasional 50/60 hour week.

There's probably a business idea there.

So they use whatever the latest angular clone is.

But you can see for yourself. Have a look at most jobs at start ups, they're always javascript/ruby/python/fancy new framework or mobile apps to reinvent online shopping or web site analytics or something.

They rather have naive young developers willing to work constant overtime, to get the fancy javascript frontend web page out faster.

The story about Ionic seems a little ridiculous. And while I sympathize for Stamos, surely there must be more than age being the difference for raising funding. Even if it is a big factor - I can't imagine all VCs being idiots, seeing a better product in an obviously valuable market and then passing.

The narrowest experience is actually amongst the mid/late 20 somethings in our group. I'm not sure if it is that lack of systems experience, not much exposure to C and lower level languages, or what, but they need more mentoring than what I recall needing at the same age.

I'm currently doing that for a couple of them and it is actually both challenging and interesting. Challenging mainly in how to convey tasks, teach them troubleshooting (without the hand holding), and a few other items. Interesting because we all learn differently and seeing how others approach problems either reminds me of my own trials or forces me to think out of the box on how to explain things.

Personally, I've always been a bit of a control freak when it comes to development -- I want to know system level through whatever level I am developing at. This often includes system administration, database management, etc. This has become much more challenging as new technologies come about -- so in those cases, say NoSQL, I will focus on one or two solutions rather than trying to understand each. Build a basis for the concepts, where it is useful, and then test, collect data and reevaluate.

There are red flags that you can easily spot in a job interview or job posting that indicate that the employer wants 80-hour weeks. And who signs up for 80-hour weeks? Naive young people who don't value their time and don't have other commitments, like side projects or family.

It's easier to gauge over the phone or in person. It's often the way things are said that act as a trigger. If a founder works 60-80 hour weeks, it's going to be expected that you will too.

Much of my early career success can be attributed to working with many senior engineers who taught me a lot very quickly, given their knowledge and experience.

There is also reverence/nostalgia for "pioneers" in my field. It's fun to tease them about punchcards, but it's also great to hear their stories about their experiences when they first started as programmers.

Then again I'm 33 so my opinion no longer matters.

As a early-twenty-something I only know a relatively small number of engineers 30+, and have only worked with a handful. Compare that to the dozens of engineers my own old that I know, and have worked on projects together. If I founded a company tomorrow I know which 4 friends from college I would want on my team, they're all other twenty-somethings.

The only engineers over 25 I have worked with (excluding open source projects) were my bosses at previous companies. I simply wouldn't know who to hire. Anyway, would any self-respecting engineer take a job at a company found by one of their interns or recent graduates from a few years back? I highly doubt it.

In my hypothetical would I really hire someone who was twice my age? Probably not. To be honest I'd be afraid of their experience. I'd feel maybe their my training wheels. They have a lot more experience than me, will their experience take over my company's vision. Part of the mentality as a twenty-something founder is proving yourself, be that to your colleagues, your peers, your parents, or whoever said you just wouldn't make it.

I find it hard to find other twenty-somethings hiring many people twice their age in the early days. Maybe without even realising it a culture similar to that of college creeps in. Every new hire creates culture, and from my hypothetical I don't have a very diverse team to start with if I start with college friends and other twenty-somethings.

Somewhere in the early days no one seems to be spotting the 'culture' problem start-ups are creating. Was this problem unintentionally created? Or was this problem created sub-consciously created intentionally? Would I as a twenty-something founder sub-conciously create a company where my Dad or my even my cool Uncle wouldn't want to work at? Probably.

I demand a very high premium for the work I do for others, and if I were going to start my own business, I wouldn't hire inexperienced people to do it with. I know the people I need to know to get financing/sales/engineering/etc. and they all have proven successful track records. At best you could bring passion and new ideas, at worst your college culture would creep in.

Don't get me wrong. I enjoy working in environments with younger developers. Mentoring new developers is one of the most rewarding things I do. But my employers have me do it because hiring young folks is a cost of doing business.

That said, I don't think anybody is worried about ageism creeping into 3 person ramen startups. The issue is 2 fold A) if your startup becomes successful enough to need my expertise, and you don't hire me because you don't see the value of experience, that is bad for both of us. B) There currently seems to be severe bias in SV investors against older founders and/or startups that employ early stage experienced folks. Paul Graham has this bias and is proud of it. That is the ageism that gets me upset.

Finally, I will say, writing good software is a craft. Like all crafts, learning from experienced craftsmen is central to getting good at it. If writing good software is something that is important to you (it needn't be, and might even be detrimental) you need to go meet and work with older developers.

In order to do new kinds of work, I had to turn down jobs for the boring stuff I knew I could do. I chose to work on stuff that scared me.

So: work on things that scare you. Things that you find mysterious. Things where the machine teaches YOU, not the other way around.

Sooner than later.

On the other hand there is a basic cost to each employee regardless of salary, so the higher pay is not proportionally as high as comparing salaries.

On the gripping hand, older employees often have families, who incur more expense for health care and so on. You can expect older people to have health issues on their own, too. This is a fairly big deal in the US, where the health care payment system is broken.