Hacker News new | past | comments | ask | show | jobs | submit login

One of the biggest indirect causes of ageism I've seen is the traditional career path forced many engineers out of engineering - there is/was an attitude at places like IBM of: "If you want to make bank, you need to go into management or sales". Years later, an engineering crunch makes engineering into "where the money is", but you largely lost a generation of technical experience that took a break of a decade or two.

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 think this is a huge part of it, folks who stop "keeping up" with the technology eventually find there is a huge amount of catching up to do. When that happens, especially if there isn't a lot of runway, it can be difficult.

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.

>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.

I'm not sure I see this:

    > The first is if you have only six months of experience
      doing something your pay is likely to reflect that.
My experience is building things has very little to do with the current frameworks and languages. Building a payroll system with a NoSQL back end and an AWS front end is "different" than building the same with an Xwindows client and an Oracle back end, but the things that may a payroll system "good" or "bad" often have nothing to do with the bricks and mortar and more to do with the kinds of things that typically go wrong or requirements that are left unstated. Someone with 20 years of experience writing programs will often know that part much better than someone who has yet to experience them.

   >  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.
That however is what sounds like actual age discrimination, that might be like not hiring a woman because "Darn it she decides to have a kid and then what? Force me to pay maternity leave? No thank you!" or "Hire that blind guy? Really like we all we need around here is someone whose computer keyboard costs more than a Retina Macbook, No thank you!" or any number of people "not like you."

   > Who do you think is going to be more productive?
     Who's going to put in 16 hour days at crunch time?
That is a good question, but one where the answer might surprise you. One of them might not have to put in 16 hours a day a crunch time, and one of them might be more productive in 6 hours than the other is in 12.

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

Honestly I've found for the most part that those who work 6-9 hours get more done than those who work 10+. Usually those spending 10+ are playing catchup or learning a new technology at the same time.

I recently had an interesting experience interviewing with a startup (which shall remain nameless). During the interview process, we had a nice discussion about sustainable development practices, and I talked about my willingness to put in the occasional long day as needed. When we got to the point where they expected me to work 60+ hours a week for the next year, they cut me loose.

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).

>That however is what sounds like actual age discrimination...

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.

"They have the same experience with whatever the latest thing is."

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 would still choose the 50 year old. If he has a family, he's more likely to be loyal. If he's not an alcoholic, he's much more likely to produce decent work. In fact, a programmer that has to put in 16 hour days at crunch time is either badly managed or a terrible programmer. Most experienced programmers can do as much or more work in half the time. Finally, there's the issue of experience, one where the younger programmer will always come in second. So the older programmer has the advantage in every case, as an engineer would in any other discipline.

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

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.

I'd like to know where you work that you can say "fuck you" to overtime during crunch period. Because, you know, I might like to work there. Seriously, contact me. :) My email is in my profile.

This is what I guessed before I started following profile data traces:

* 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.

Yes, I'm in Romania, but I've been working exclusively with Sillicon Valley companies and have been working within startup environments for the last 5 years.

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.

>Being able to say NO is not a matter of where you work, but rather one of actually saying NO.

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.

Eh, my personal experience has been that no one actually asks you to stay late for anything. A couple of people seem to do so without being asked, but if a deadline is missed, the reaction is generally, "Well, let's examine the process for what we're doing wrong. Are we overcommitting? Were the specifications wrong? Are the engineers being randomized too much? Did we change the specs midway through?" Etc. It's never "Oh, you didn't put the extra hours in."

But that's just my personal experience.

In the mid '90s I had a job working in a company doing logistics software. Every Friday about 2:00 my manager would come around and say "We're really behind on our delivery, so the team is coming in tomorrow for a half day. I'll buy everyone pizza for lunch."

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.

You mention IBM, one aspect that always bugged me was upto the mid 80's they had a thing about people with beards and was some sort of unwitten policey (never worked for them) that nobody could have a beard and any intervewing with them entailed making sure you had a good shave. I worked with a chap at RAND who went onto work for IBM porting AIX onto the mainframe (least that was the initial project he was joing for) and was somewhat begrudged that he would have to shave his beard of just to get the job irespective of his ability.

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?

At some point, IBM decided catering to wall street was more important than doing real work. Take a look at Cringely's articles on IBM. I've known people that worked as contractors at IBM Almaden and as the transition was occurring, they went out of their way to not end up on the radar -- the impression I got was that management being aware of your project was a risk for being cut. This was even worse for the rank and file full timers.

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.

Sounds about right, yes IBM did also change when they focused more in offering services. Became slower in there replies too issues but still got there. One project I came across was issue with SAMBA and logging around the year 2001 and quickly knocked up a wrapper for the SAMBA code to trap and log what was needed to be logged. Took IBM a week to confirm my 30 minute solution would work and was the right approach and then they only ended up at that conclusion after talking to Jeremy Allison.

I worked for a company once that had a suggestion box. If you made a non-anonymous suggestion that wound up saving the company money you got 10% of the savings over 2 years. While I was there no one got rich off of it but a few people got some nice bonuses. I don't understand why more people don't do this.

I worked as an intern at IBM last summer. It seemed like my entire team was a stagnant pool from the 70's. The languages were C and HLASM, 'high level assembler.' None of my managers knew anything about newer languages like Golang or Haskell. We built hash tables by converting strings to integers and then using modulus. They laughed at the idea of a Linux machine being useful as a server.

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.

> We built hash tables by converting strings to integers and then using modulus

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.

Ah, ok. Using something like loose-loose as hash function is indeed a terrible idea.

How old are the creators of Golang and Haskell ?

Ken Thompson is 71, Rob Pike is ~58, Haskell creators seem to be in their mid 50s.

Haskell was designed by a committee, so it's going to be difficult to find ages for all of them, but Simon Peyton Jones, the best known of the creators, is 56.

That has more to do with IBM / that dept within IBM than the individuals.

My parents worked a long time at IBM - Dad from about '70-'00, give or take a couple years, and Mom from '77-'86, then again in the late '90s for a few years. I don't think it was an ageism culture per se in terms of older people being less valued, but from both of them, the career advancement was in either sales or management. I don't think the vision for either was to stay technical and advance on the basis of technical ability.

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.

Re ageism, it depends on where you are and what you are working on. I know and have known many who have 30, 35 and 40 years in and stayed in engineering.

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.

This makes a lot of sense. It's something that I feel is changing nowadays thankfully.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact