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

There's a reason why ageism exists in the industry and it isn't because of some undeserved stereotype about old dogs not being able to learn new tricks.

1) Most business-critical projects have long lifetimes. There's a reason why banks are still running COBOL and mainframes, and why Java's continued promise of backward compatibility with every new release is so valuable to companies.

2) Maintaining legacy systems is a bitch. Nobody likes maintaining legacy systems.

3) Therefore no employer wants to hire somebody who writes code which almost immediately turns into legacy code, either because it's not tested, or not written using modern language features designed to make the language safer, etc.

4) Learning to write code in a modern fashion requires continued education.

5) Employers will not budget or pay for this continued education in a no-compete-clauses-are-illegal environment where smart employees will take the training and run to another employer willing to pay for the benefit of another employer which already put in the legwork of investing in that employee.

6) Employees therefore need to spend significant time educating themselves on their own time. This is great for the minority who are computer geeks who treat it as a hobby and it's terrible for everyone else.

7) Most people will not spend personal time educating themselves, because they prefer to invest that time in friends and family. This is all the more true, not less true, after one's children are grown.

8) Therefore they slowly become unemployable as their skill set turns obsolete.

9) Therefore employers have a hard time finding older people who do have that combination of a modern skill set and decades of general industry experience. And it's for the same reason it was difficult to hire any programmers at all in the 90's, because the competent labor pool (then in general and now in the older age group) is basically limited to computer geeks.

10) Continued interviews of older people who did not bother to keep their skill set modern and honed creates a stereotype that old people aren't "smart".

It's not a problem that some Chief Diversity Officer at some Big Four company can solve, because they're either going to literally fight human nature (people desiring quality time with their families) or they're going to adapt an affirmative action policy that'll only make the problem worse, as prefer-false-negative hiring policies set up to protect codebases from incompetence get overturned for what's essentially a political reason, breeding resentment.




This is an argument built on one stereotype/assumption after another.

1) Many business critical projects have relatively short lifetimes. The use of hyper-legacy (avoiding the use of the word 'ancient' here) systems has more to do with the stability of well-known domains like accounting than any other factor. Other systems are business critical but meant to solve a short-term need, eventually being replaced by a better or more well-informed implementation.

2) Don't presume to know what everyone else likes to do.

3) Your implication is that "old dogs" are going to write code which is immediately legacy: they don't write tests (which is by no means a guarantee that code won't become 'legacy'); they don't use modern language features; indeed, that code without the use of modern language features is itself legacy.

4) I won't argue with this one, but with the same assumption you make in #3.

5) No-compete clauses are only illegal in a few jurisdictions like CA (in the US anyway). "Smart" employees tend to stay with employers that have an ethos of investing in their employees. In any case, I used to teach corporate training classes, and I can assure you that there is a healthy market of employers who do this.

6) Yes, people of all ages need to spend a significant amount of time investing in themselves, including 20-somethings. This is not a new thing, and indeed, "old dogs" are better at sniffing out where that time is best spent.

The remainder of your argument are conclusions built on faulty premises.

The problem of ageism in tech is multifaceted to be sure, and we all know developers who fit into the stereotypes you promote here. But to say that they are the primary cause is part and parcel of that same ageism, and ignores: * the role of capital in providing vast sums of money to inexperienced youth; * the hubris of that same youth; * the lack of diverse and inclusive cultural values within the US as a whole and Silicon Valley in particular; * and far from the least, the social and cultural aspects of media in influencing stereotypes (Forbes' annual 30-under-30, anyone?).


Therefore no employer wants to hire somebody who writes code which almost immediately turns into legacy code

But what is "legacy" or not is not to do with technology, but fashion. Let me give you an example: everyone rants on here about what awful languages PHP and JS are. Is COBOL really a worse language than either of those? If so why? What algorithms or data structures can't be implemented in it? What tooling doesn't exist?

The only reason COBOL is considered a legacy language is because it's unfashionable, and a large part of that - I'm not even kidding - is the clothes COBOL programmers used to wear have fallen out of fashion. There's actually no reason that you couldn't use it for any application you might want to write today, and it would probably be more productive to do so than some modern languages...


COBOL has its limitations for sure, but I am an oddball because I love it. I took it for two semesters as part of my master's degree and am keeping an eye out for COBOL jobs by me. I would love to work in COBOL day in and day out.

The hardest thing about COBOL is the mainframe it has to run on. Without that access, I haven't done much coding outside of class.


"Learning to write code in a modern fashion requires continued education" - what does that even mean? It's like telling someone they need to learn to drive in a modern car. The car is modern, the driving isn't.




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

Search: