4 ms·

Stories like this one terrify me. No matter how young you are today, someday not too long from now you'll be 40+ and on the receiving end of this type of discr

Stories like this one terrify me. No matter how young you are today, someday not too long from now you'll be 40+ and on the receiving end of this type of discrimination. Is that the kind of industry we want to be?

stinos 12y ago
But we don't know the full story (for each individual) - we don't know if it really is discrimination based on age or if there are other things going on. I've seen both things happen in medium sized companies so I won't be surprised if it's the same for Microsoft (or other major companies for that matter) - case 1: a guy in his fifties writing C++ like it's C with classes in the same style he did 20 years ago. Every piece of code is a complete trainwreck. I could go on for hours on how bad it is. Anyway, the programs he creates like that sort of work. Barely. But because there isn't anyone else to do his job, managment is stupid and too lazy to find someone else and rather waits until it explodes in their faces (i.e. when he retires), he can stay. Until one day a new manager steps in and immediately sees the problem and lets the guy go. Would you really call this discrimination or rather the proper thing to do? - case 2: the opposite. Decent guy in his fifties, hard working, always learning, writing proper code, not afraid to speak up. The letter eventually yielding him fired because (again) of stupid managment: one manager able to convince the rest he's too old and too costly too keep, rest of the pack too lazy too stand up and just let it happen.. That is discrimination.
- yummyfajitas 12y ago
  There is also a trickier and more interesting case 3: Experienced guy in his 50's, seen it all before. Remembers the era of object databases, knows why SQL was invented, and shuts down his hipster colleague's plans to use Mongodb. Remembers CORBA, SOA and J2EE and is skeptical about microservices. Understands why logging/metrics/dependency injection is necessary and pushes RoR guys to use more verbose syntax to support it. Younger folks dislike him because of this. There is conflict. Management has a real problem, since they both need experience but the senior guy can't build everything on his own.
  - 1stop 12y ago
    dependency injection isn't needed in RoR, as mocking/stubbing is so simple, and built in (with RSpec, say)... (Same with metrics, they can easily be injected into the entire object tree). Logging sure, you need to write some of that. There are also arguments for NoSQL dbs as well, some times old knowledge is exactly that. This doesn't seem to be a compelling example... But alas, I think I've taken this off topic.
    - BugBrother 12y ago
      yummyfajitas' point about noSQL DBs was -- the old guy saw DBs before SQL was created and understand the trade offs.
    - pionar 12y ago
      > dependency injection isn't needed in RoR, as mocking/stubbing is so simple, and built in (with RSpec, say) Disclaimer: not a RoR guy. Dependency injection isn't about unit tests. Dependency injection is about weak dependencies, easier refactoring, and preventing bad design decisions from being a disaster 5 years down the line. Dependency injection is a good idea no matter what the language/framework is. That's the point of the parent comment. A dev in his 50s would point these things out.
      - barrkel 12y ago
        Dependency injection in practice is almost always implemented for tests. In terms of architecture, it's usually a case of YAGNI. Every dependency injected is a configuration point that is almost never altered, except for mocks in testing. When this style infects a whole codebase, it makes it far harder to read and navigate, because code flow is dependent on runtime data flow. Heavy use of indirections that only ever go to the one place is a bad code smell, and it's a stench over the entire field of enterprise Java. Code that is easy to read is easy to refactor. Except for natural architectural chokepoints that are typically intrinsic to the problem being solved, you're fooling yourself if you don't think architecture changes are needed for most refactoring - dependency injection isn't buying you what you think you're buying. Every injection point you create is a prediction about the future, about the possibilities of change, but there's one gotcha: the future is hard to predict, so most of your decisions are wrong. You're better off being agile, following YAGNI, doing the simplest thing that will work, and altering it when requirements change.
Filthy_casual 12y ago
I'm terrified to follow the start-up route as well, because I'm 34 and I know that a) Silicon Valley is notorious for its implicit ageism b) Once I'm 40 and have 4 years of experience working in start-ups I'll be dismissed from either getting hired or getting funded because I'm old. The only thing that makes this topic worthy of upvoting is because people identify a company doing things an entire culture does. Sure you can bring a lawyer and pull a company to the court (good luck proving that they discriminated you based on age) but a culture? How do you even do that? You can't. This is why I find it hypocritical that people act appalled on the idea that a company is doing what everyone admits a culture does but for the company is punishable and "well deserved" to be punished for it. In fact, I imagine there will be some sort of standing ovation somewhere in the world when an ageism case is won against ANY Microsoft, whereas for the culture is just "how things are" and it's your job to avoid it. Funny, isn't it?
wsc981 12y ago
At least in The Netherlands it seems many older employees can get by perfectly well as freelancer in IT. And as freelancer at least you have much more control over your own future, instead of linking ones future to some specific company. The times have changed anyways. Most people won't be working at the same company for most of their lives and to me that seems like a bad investment anyways. It's time that people (especially in IT) start shaping their own future.

stinos 12y ago

But we don't know the full story (for each individual) - we don't know if it really is discrimination based on age or if there are other things going on. I've seen both things happen in medium sized companies so I won't be surprised if it's the same for Microsoft (or other major companies for that matter) - case 1: a guy in his fifties writing C++ like it's C with classes in the same style he did 20 years ago. Every piece of code is a complete trainwreck. I could go on for hours on how bad it is. Anyway, the programs he creates like that sort of work. Barely. But because there isn't anyone else to do his job, managment is stupid and too lazy to find someone else and rather waits until it explodes in their faces (i.e. when he retires), he can stay. Until one day a new manager steps in and immediately sees the problem and lets the guy go. Would you really call this discrimination or rather the proper thing to do? - case 2: the opposite. Decent guy in his fifties, hard working, always learning, writing proper code, not afraid to speak up. The letter eventually yielding him fired because (again) of stupid managment: one manager able to convince the rest he's too old and too costly too keep, rest of the pack too lazy too stand up and just let it happen.. That is discrimination.

yummyfajitas 12y ago
There is also a trickier and more interesting case 3: Experienced guy in his 50's, seen it all before. Remembers the era of object databases, knows why SQL was invented, and shuts down his hipster colleague's plans to use Mongodb. Remembers CORBA, SOA and J2EE and is skeptical about microservices. Understands why logging/metrics/dependency injection is necessary and pushes RoR guys to use more verbose syntax to support it. Younger folks dislike him because of this. There is conflict. Management has a real problem, since they both need experience but the senior guy can't build everything on his own.
- 1stop 12y ago
  dependency injection isn't needed in RoR, as mocking/stubbing is so simple, and built in (with RSpec, say)... (Same with metrics, they can easily be injected into the entire object tree). Logging sure, you need to write some of that. There are also arguments for NoSQL dbs as well, some times old knowledge is exactly that. This doesn't seem to be a compelling example... But alas, I think I've taken this off topic.
  - BugBrother 12y ago
    yummyfajitas' point about noSQL DBs was -- the old guy saw DBs before SQL was created and understand the trade offs.
  - pionar 12y ago
    > dependency injection isn't needed in RoR, as mocking/stubbing is so simple, and built in (with RSpec, say) Disclaimer: not a RoR guy. Dependency injection isn't about unit tests. Dependency injection is about weak dependencies, easier refactoring, and preventing bad design decisions from being a disaster 5 years down the line. Dependency injection is a good idea no matter what the language/framework is. That's the point of the parent comment. A dev in his 50s would point these things out.
    - barrkel 12y ago
      Dependency injection in practice is almost always implemented for tests. In terms of architecture, it's usually a case of YAGNI. Every dependency injected is a configuration point that is almost never altered, except for mocks in testing. When this style infects a whole codebase, it makes it far harder to read and navigate, because code flow is dependent on runtime data flow. Heavy use of indirections that only ever go to the one place is a bad code smell, and it's a stench over the entire field of enterprise Java. Code that is easy to read is easy to refactor. Except for natural architectural chokepoints that are typically intrinsic to the problem being solved, you're fooling yourself if you don't think architecture changes are needed for most refactoring - dependency injection isn't buying you what you think you're buying. Every injection point you create is a prediction about the future, about the possibilities of change, but there's one gotcha: the future is hard to predict, so most of your decisions are wrong. You're better off being agile, following YAGNI, doing the simplest thing that will work, and altering it when requirements change.

Filthy_casual 12y ago

I'm terrified to follow the start-up route as well, because I'm 34 and I know that a) Silicon Valley is notorious for its implicit ageism b) Once I'm 40 and have 4 years of experience working in start-ups I'll be dismissed from either getting hired or getting funded because I'm old. The only thing that makes this topic worthy of upvoting is because people identify a company doing things an entire culture does. Sure you can bring a lawyer and pull a company to the court (good luck proving that they discriminated you based on age) but a culture? How do you even do that? You can't. This is why I find it hypocritical that people act appalled on the idea that a company is doing what everyone admits a culture does but for the company is punishable and "well deserved" to be punished for it. In fact, I imagine there will be some sort of standing ovation somewhere in the world when an ageism case is won against ANY Microsoft, whereas for the culture is just "how things are" and it's your job to avoid it. Funny, isn't it?

wsc981 12y ago

At least in The Netherlands it seems many older employees can get by perfectly well as freelancer in IT. And as freelancer at least you have much more control over your own future, instead of linking ones future to some specific company. The times have changed anyways. Most people won't be working at the same company for most of their lives and to me that seems like a bad investment anyways. It's time that people (especially in IT) start shaping their own future.