4 ms·

My thoughts are that ageism in IT is a natural consequence of not valuing experience. Rather for many employers what is sought is simply someone, smart, fast l

My thoughts are that ageism in IT is a natural consequence of not valuing experience. Rather for many employers what is sought is simply someone, smart, fast learning, motivated, compliant, enthusiastic, loyal, and a good team fit, with perhaps boot camp level knowledge of the latest in shiny framework(s). Many inexpensive 18 year olds can fit that description well, particularly in regards to their being enthusiastic, compliant and motivated. It helps that these are values that inexperienced managers and interviewers can actually assess, along with (inapplicable to the position) canned answers to questions about data structures and algorithms.

mojuba 7y ago
> My thoughts are that ageism in IT is a natural consequence of not valuing experience. Exactly, which is often reflected in job specs. You rarely see a requirement to have 10, let alone 15 or 20 years of experience as a requirement. When the application is automated you can get a drop down menu that stops at 5+, for example. I once complained about this to Hired.com; they didn't react at the time but years later they added more options up to 15+. This is a Dunning-Kruger effect of sorts. When those hiring have no more than 5 years of experience, they have no idea that the difference between 10 and 5 is as big as between 0 and 5, and so on. Unfortunately you have little chance of seeing the value of experience if you lack it yourself.
- sverhagen 7y ago
  There's probably a lot of things where the extra years of experience over a certain number doesn't matter much anymore. I don't think you can learn as much about many things in the second five years as you did in the first. Other factors then play a much bigger role anyway, such as: did you use whatever you claim experience in once a week or all the time.
  - mojuba 7y ago
    There are things where it's not about learning as much as about the quality of code you produce within the same timeframe. My personal record of rewriting a big product was reducing a 150k LOC project to 7k lines with the same functionality and then some more. Now compare the cost of maintenance of 150k lines of code vs 7k. That literally translates to a lot of (saved) money for the company. While that one was probably a bit extreme, even 3x or 4x reduction can be a big win. These things come with experience more than "learning" in the traditional sense.
    - world32 7y ago
      Fair point but do we have any actual data around the correlation between years of experience and value to a company? Admittedly its probably a hard thing to measure.. Because I can also tell you another anecdotal example of some developers who each had 20+ years experience each and we're quite high ranking they company they worked at: - They would re-invent the wheel constantly: the framework provided lots of functionality which had been developed and battle tested by thousands of other developers but they couldn't be bothered to learn what was available to them so wrote a lot of functionality from scratch which was usually far more buggy than the open source code available. - classes which had literally 10,000+ lines of code in them. - of course the idea of following SOLID principles was never ever going to happen - a general view that they were the experienced ones who "just made it work and got on with the job" while the younger programmers or those who followed more modern practices were seen by them as being "airy-fairy" and worried about things that didn't matter. that argument might have held weight if the application they built wasn't so awfully riddled with bugs and so poorly architected that mainting it and building new features took ages. - They had all been working at the same company for at least 15 years, so they were able to ignore the advances made in software development in that time and carry on with their old ways. Of course they could still code new features and fix bugs but they didn't realise that what they were doing could be done in a much much better way. I'm not saying all old developers are like this. But if somebody is able to tell me that older developers are better because X, then they should be able to accept somebody else disagreeing and saying that older developers are worse because Y. You can't have it both ways.
jpindar 7y ago
Are you saying only young people are "smart, fast learning, motivated, compliant, enthusiastic, loyal, and a good team fit"?
- aryehof 7y ago
  No.
tabtab 7y ago
I've seen CRUD reinvented about 20 different ways, and I'm sure more are still out there. The industry throws things out and starts over, often due to "fashion", NOT logic. It's more work to create the same CRUD app now than it was 20 years ago. We are devolving because the industry chases fads instead of productivity. (There are exceptions, but it requires more things to go right, including managers who know when to say "no".) We still do our work on 99% desktops at my org, yet the UI's are using frameworks optimized for tablets, which wastes a lot of screen real-estate, making the UI tedious. Fear of Being Left Behind (FBLB) gave everybody Tablet Fever. We hit the wrong target, and are doing it again with microservices. I warned the architect they are not a good fit for our org, but he has FBLB and dismisses me as an ol' fuddy-duddy. If you make IT like the music and clothing business, then it's a fashion chase, and usually the fashion business doesn't want older people also. If the industry randomly changes like a genetic algorithm of techniques, older people will on average not be able to keep up. Older brains are just not as good at that, on average. Instead, if tools and techniques are tuned and perfected based on incremental lessons of the past and present, then EVERYONE will be more productive. Repeated throwing-out-and-starting-over is expensive.

mojuba 7y ago

> My thoughts are that ageism in IT is a natural consequence of not valuing experience. Exactly, which is often reflected in job specs. You rarely see a requirement to have 10, let alone 15 or 20 years of experience as a requirement. When the application is automated you can get a drop down menu that stops at 5+, for example. I once complained about this to Hired.com; they didn't react at the time but years later they added more options up to 15+. This is a Dunning-Kruger effect of sorts. When those hiring have no more than 5 years of experience, they have no idea that the difference between 10 and 5 is as big as between 0 and 5, and so on. Unfortunately you have little chance of seeing the value of experience if you lack it yourself.

sverhagen 7y ago
There's probably a lot of things where the extra years of experience over a certain number doesn't matter much anymore. I don't think you can learn as much about many things in the second five years as you did in the first. Other factors then play a much bigger role anyway, such as: did you use whatever you claim experience in once a week or all the time.
- mojuba 7y ago
  There are things where it's not about learning as much as about the quality of code you produce within the same timeframe. My personal record of rewriting a big product was reducing a 150k LOC project to 7k lines with the same functionality and then some more. Now compare the cost of maintenance of 150k lines of code vs 7k. That literally translates to a lot of (saved) money for the company. While that one was probably a bit extreme, even 3x or 4x reduction can be a big win. These things come with experience more than "learning" in the traditional sense.
  - world32 7y ago
    Fair point but do we have any actual data around the correlation between years of experience and value to a company? Admittedly its probably a hard thing to measure.. Because I can also tell you another anecdotal example of some developers who each had 20+ years experience each and we're quite high ranking they company they worked at: - They would re-invent the wheel constantly: the framework provided lots of functionality which had been developed and battle tested by thousands of other developers but they couldn't be bothered to learn what was available to them so wrote a lot of functionality from scratch which was usually far more buggy than the open source code available. - classes which had literally 10,000+ lines of code in them. - of course the idea of following SOLID principles was never ever going to happen - a general view that they were the experienced ones who "just made it work and got on with the job" while the younger programmers or those who followed more modern practices were seen by them as being "airy-fairy" and worried about things that didn't matter. that argument might have held weight if the application they built wasn't so awfully riddled with bugs and so poorly architected that mainting it and building new features took ages. - They had all been working at the same company for at least 15 years, so they were able to ignore the advances made in software development in that time and carry on with their old ways. Of course they could still code new features and fix bugs but they didn't realise that what they were doing could be done in a much much better way. I'm not saying all old developers are like this. But if somebody is able to tell me that older developers are better because X, then they should be able to accept somebody else disagreeing and saying that older developers are worse because Y. You can't have it both ways.

jpindar 7y ago

Are you saying only young people are "smart, fast learning, motivated, compliant, enthusiastic, loyal, and a good team fit"?

aryehof 7y ago
No.

tabtab 7y ago

I've seen CRUD reinvented about 20 different ways, and I'm sure more are still out there. The industry throws things out and starts over, often due to "fashion", NOT logic. It's more work to create the same CRUD app now than it was 20 years ago. We are devolving because the industry chases fads instead of productivity. (There are exceptions, but it requires more things to go right, including managers who know when to say "no".) We still do our work on 99% desktops at my org, yet the UI's are using frameworks optimized for tablets, which wastes a lot of screen real-estate, making the UI tedious. Fear of Being Left Behind (FBLB) gave everybody Tablet Fever. We hit the wrong target, and are doing it again with microservices. I warned the architect they are not a good fit for our org, but he has FBLB and dismisses me as an ol' fuddy-duddy. If you make IT like the music and clothing business, then it's a fashion chase, and usually the fashion business doesn't want older people also. If the industry randomly changes like a genetic algorithm of techniques, older people will on average not be able to keep up. Older brains are just not as good at that, on average. Instead, if tools and techniques are tuned and perfected based on incremental lessons of the past and present, then EVERYONE will be more productive. Repeated throwing-out-and-starting-over is expensive.