7 ms·

There is an assumption that "old" means "experienced" which is not necessarily true. There are people who transition to programming from other fields and are "o

There is an assumption that "old" means "experienced" which is not necessarily true. There are people who transition to programming from other fields and are "old". Their value shouldn't depend on whether or not they fit the stereotype of "old timer hacker geeks". They should be judged by their skills, the same way the young ones are being judged.

Juliate 6y ago
Actually, they should be judged by what they can and do contribute to the team, whatever that is. Skills is a subset of that.
- virgilp 6y ago
  This (and original) statement(s) are all good and nice, but meaningless (in the same way as "there should be no hunger in the world because we have enough food"). Ok, we should judge people by what they can and do contribute to the team. The billion-dollar question is, HOW? Humans are extremely skilled optimizers - give them an objective metric and they'll game it for maximum benefit; make it subjective and it can be better or worse - but in either case, you'll no longer have any agreement on "what they contribute to the team".
  - austincheney 6y ago
    > HOW? * Documentation - Can they write? * Potential - Can they provide original solutions to problems? Do they need hand holding? * Initiative - Do they need a signal from a starting gun or are they self-entertained with word products for the team? These are all identifiable maxims.
    - virgilp 6y ago
      I'm not saying "people can't be managed" and "one can't evaluate the performance of a programmer" - that'd be obviously false. What I _am_ saying is that it's an art not a science - very hard to teach, impossible to scale. Take your example with "Documentation" - if you measure anything objective (words written, number of functions/features that have associated documentation) and tie it with the performance evaluation, those metrics will soon become meaningless.
      - athenot 6y ago
        Poor metrics are meaningless regardless of what you try to measure. In the example of documentation a better metric might be a composite value of (i) how many wiki articles a developer has written, weighed 0.33 and (ii) how useful on a numerical scale his/her peers rate the documentation produced, weighed 0.67. This is just an example but it's a composite of perceptual and objective, with the perceptual being a lot more important (and to prevent gaming the system by writting lots of useless articles).
        virgilp 6y ago
        It's all in the details. If I get to pick who rates "how useful", this translates into a general "how well liked by my colleagues am I" (general problem with 360* feedback; I'm not saying it's useless, but it does have its limitations)
        tstrimple 6y ago
        The way I've experienced it is that when a measurement becomes a metric, it ceases to be a good measurement. When people's bonus is tied to a measurement, they will find creative ways to influence that measurement which, in many cases, defeats the purpose of what it was trying to measure in the first place. It's not simply a matter of choosing the right measurements. It's also a matter of how you incentivize those measurements. When I worked at Microsoft one of the teams I was adjacent to had a metric on number of new apps in the Windows Phone app store. So the teams went out and got a bunch of college students to build shitty apps in bootcamp style working groups. Suddenly the number of apps isn't good enough, so they added review metrics. Now those teams add a "let's all rate each other's apps" portion to the bootcamp taking you even further away from the results you're trying to obtain.
      - brlewis 6y ago
        If it's true that one can evaluate the performance of a programmer, what does that mean? Can it be reduced to a vector of scalar values? I hate doing performance reviews, and I especially didn't like when at a former employer I was asked to stack rank programmers. I feel like it's a task that's so difficult to get right, I can't even think of a wrong way to do it that's useful.
    - rezeroed 6y ago
      Re initiative. I've had jobs which did not want initiative on a macro level - my manager would tell me what was wanted, I'd go away and make it happen. Those managers loved me. My current role, bullshitted into a "devops" role, I'm expected to spend my days showing initiative - building things that I think will be useful - and which never get used. I'll take the former jobs. What I have now sounds like freedom, it feels pointless and torturously demotivating. Do my managers know what they're doing? Do they have any roadmap? Can they see shortcomings in our systems? Is it mushroom management or cluelessness? I think these positive sounding words eg "initiative" are not positive - they are context dependent. "Potential" - if you need someone writing endless crud, if they have potential are they going to stick around? Do you really want/need Achilles? Are you really leading the Trojan army? Maybe you just need sticky tape, not a welding torch.
      - virgilp 6y ago
        You touch on two issues here: one, that there's an entire gamut and not a binary "senior/junior"... and management just LOVE to present requirements like "Can walk on liquid water; God asks him for advice on how to run the world" when you ask "what do I need to do in order to get to next level", especially in big corporations [1]. The second is that different types of people prefer different styles of working and sometimes forget there is another side (multiple "other sides", really). A team needs to be a mix of capabilities and personalities to be successful - a team of 100 identical individuals would likely fail, even if all them are Peter Norvig). So, you need people that are "senior" in the sense that "knows the business well enough to provide different perspectives" (and for those "shows initiative" is critical) but you also need specialists where "senior" means "knows technology X really really well". Say, a DBA - can keep your database up, can write efficient queries to retrieve information that you want; but doesn't know sh*t about what information would be interesting to retrieve. Or whether it's a good idea to keep some information X in the database, considering the various business, legal, social, cost perspectives. > Do my managers know what they're doing? Here's the thing: I believe nobody _really_ does. Sure, some know more than others, but in absolute terms, we're all basically guessing. That's why people insist on engineers that "show initiative" - not because they're always right, but in an environment where we don't _really_ know what we're doing, people yelling different perspectives are valuable. However, as mentioned above - not all senior engineers want or are inclined to show this kind of initiative; and it's unfair to penalize those kinds of engineers, because we _need_ the different types of personalities. [1] FWIW I believe the reality is , always, that you need to (A) work on a successful project; and (B) be generally liked by your colleagues and maybe managers. For very senior titles, also (C) have a large network of connections within the company - i.e. work on many things, or on one thing but a thing that is used by many teams/ really popular)
  - Juliate 6y ago
    How? Work with them. Pay them enough as they don't have to think about it. Objective metrics are good if you think you can measure accurately for all individuals at the macro level. You may not need that (I mean, really _need_ it for your business to function, unless you're in the metric-tracking business). If your teams have distinct and articulate enough outputs, you can retribute each team according to its specific outputs. At the macro level, you don't need to have more details (but you still may ask). Let the team manage its own distribution of the retribution - and so on (so you do need trained managers to do it appropriately at each level).
- maratumba 6y ago
  That's a better way of putting it.
gtsop 6y ago
> There is an assumption that "old" means "experienced" which is not necessarily true. Agreed > They should be judged by their skills, the same way the young ones are being judged. Disagree, but this is my subjective opinion. Old people in general are not able to keep up with young people for many reasons. My personal stance is we shouldn't compare them as equals, but rather try to get the most out of everyone. The baseline for judging someone (to be hired or to stay in a job) should depend on the effort they put in. Actual performance should be taken into account when deciding on promotions and bonuses. This would create an environment safe for old people to keep their jobs until they retire, but also fair to people of any age to get higher salaries and roles based on their skills.
- maratumba 6y ago
  Treating people differently based on the class they belong in, in this case age, is the definition of discrimination.
  - gtsop 6y ago
    Firstly I am all in for discrimination that results in positive effects for people in need (as long as it is reasonable and not blind benefits for the sake of suposedly helping minorities) However, my solution does not judge people differently based on age. It judges everyone in a way that allows old people to fairly compete with young people on the basis of effort put in rather than pure skills/performance output.
    - reflectiv 6y ago
      We are talking about technical abilities...if you discriminate outside of that, including age, I would whole heartedly call that the bad kind of discrimination.
      - gtsop 6y ago
        I am really not sure why my point isn't clear. I am not judging people differently based on age. I observe that skills/performance is not a fair metric for old people to compare against young ones. Thus, in order to create a field of fair competition I argue that for the baseline desicisons (getting and keeping a job) people of all ages should be judged on the effort they put in, a fair metric for all ages. Then comes the second layer of judgement based on skills which decides who gets promoted or gets performance bonuses. Old people would have less chances to win in this layer of judgement but at least they can keep their jobs safe as long as they put in effort.
SteveMoody73 6y ago
I agree that age doesn't mean experience. I work in a company with a small development team and we're all around the same age group with no young programmers. In thios group we have a programmer in his early 40s, who has been programming for years, that I would still consider a "junior" programmer. He can usually perform a task but needs more guidance and checking than the other members if the team, most of which have been there time. On the other side we also had a developer work there a few years back that was in his late 50s and wrote some of the worse looking code I've ever seen. Fortunatly he didn't last long and none of his code is running in production.
- auggierose 6y ago
  What exactly is the meaning of "On the other side" here?
  - JustResign 6y ago
    I believe the best equivalent phrase would be "on the other hand" or "in contrast"
- Nursie 6y ago
  I've met those guys. The 50-something who had been in the same role 37 years, who was laid off and when hired into a new company, just couldn't adapt. The 40-something who's fine to do maintenance and the odd enhancement, but you wouldn't trust to do a major refactor or a large chunk of green-field. Some people just aren't as able, find themselves a comfort zone and stick to it. So even experience doesn't necessarily mean experience :) (This isn't to say such people aren't useful, that's a different measure.)
skohan 6y ago
Yes it's not about valuing age, but it is about valuing experience. Sometimes raw talent and problem solving ability is the most important quality to look for, but sometimes experience in the field is incredibly relevant and valuable, and can't be replaced by raw talent.
- jondubois 6y ago
  If you're young, you fit in a narrow spectrum of experience with a relatively low upper bound. If you're old, then the spectrum of possible experience is much broader. You could range from being totally inexperienced to being extremely experienced. Also, as I get older, I realize that talent plays a significant part (which is independent of age). But there is a huge problem that almost all companies don't know how to identify technical talent; they focus on the wrong attributes like ability to perform under pressure and ability to recall details. Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly; that is the real valuable talent.
  - Loughla 6y ago
    >Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly So, from my non-tech perspective, that's just every single job at every single employer. Any position I've had that has been in charge of hiring people - I am acutely aware that I can teach the position. I can teach the technical aspects and detail knowledge of how to do a job. What I can't teach is the ability to prioritize, critically think, and communicate appropriately. Those are real talents. I guess what I'm saying is - tech companies are garbage at evaluating for those things, because (I would argue) all/nearly all companies are garbage at evaluating for those things. It doesn't matter if it's a tech company, garbage company, or insurance company - they're all (again, my experience) equally garbage at finding those skills in people through their standard interview processes. If you figure out how to implement a standard interview process to evaluate for the three things you list, you will be the world's first trillionaire.
  - skohan 6y ago
Consultant32452 6y ago
Some people have 10 years of experience. Other people have 1 year of experience 10 times.
- nullsense 6y ago
  And some people have 10 years of just not very useful experience. Not the same year 10 times but 10 discrete, non-overlapping years.
- collyw 6y ago
  Ten years of experience in one tech stack will give you mastery. 1 year changes with a new language / framework / tools every time will mean you are forever a novice.
  - bdcravens 6y ago
    Ten years of experience in one tech stack that has fallen by the wayside means you're outclassed by the developer with 2 years of relevant experience.
  - ivalm 6y ago
    If you know 10 different tech stacks you probably have immense breadth and can learn/do new things easily. That’s is incredibly valuable. There is a massive difference when you are learning a new stack for 11th time vs 2nd or 3rd time. Sometimes you need people with deep mastery of some specific, sometimes you need people who have seen everything, can learn anything, and synthesize a broad view.
    - tartoran 6y ago
      That is not entirely true. After learning the n-th stack and knowing the knowledge will likely sputter out in a couple of years cycles, one is likely to learn enough to get done what needs to be done. As someone points out, few out there are true experts if they're constantly learning a new stack. And also people who want to learn all the time do get bored of learning the same thing, a lot of them branch out in different directions that are a lot less shapeshifting. Ideally I preferred learning the technology for a few years then steeping back and reaping the benefits and do stuff with it. But, there is a fear that not keeping up leads to obsolescence on the job market so we're in this constant cycle of learning new things with diminishing returns
dimmke 6y ago
I agree with this. I've known some people who've been coding for 15-20 years who just coast, and end up in senior positions because of how long they've been employed when their skills are really at the level of a 2 year junior. It's even worse in front-end, because that means their skills are that of a 2 year junior 10 years ago, they don't have any of the skills with new frameworks and techniques. If you want sloppy bootstrap laden html/css and jQuery, they're your person though.
- collyw 6y ago
  Out of interest what skills are you talking about? I am an old fart by IT standards and i have come to realise that being able to come up with an algorithm randomly is not such a useful skill considering how infrequently we actually have to do it. Being able to say "no" and getting on with other developers are far more valuable than being able to solve a soduku puzzle once you have acquired a certain level of knowledge. After that it should be about managing complexity.
  - akiselev 6y ago
    Not the OP but I largely look for experience with CI/CD workflows and release management, unit/integration/systems testing that doesn't cripple R&D, QA, distributed systems beyond a webserver & DB, and just general "philosophy of software engineering" type stuff like an understanding of the factors that led to the evolution from monolith to microservice, agile/scrum/management fad of the week, and how to make tech tradeoffs based on business goals. These are largely soft skills, not algorithmic trivia. Unfortunately, there's no one size fits all worksheet for those soft skills that HR can hand out to interviewers, so everyone gets lazy and falls back to the whiteboard BS.
  - dimmke 6y ago
    >i have come to realise that being able to come up with an algorithm randomly is not such a useful skill considering how infrequently we actually have to do it. This isn't what I'm talking about - I'm talking domain specific skill. If you're a frontend developer for instance, you should understand the new language features of JavaScript that came out in 2015-2016 and be able to use them. You should know how to use flexbox for CSS instead of floats for layout (IMO) If you're a senior developer still writing code every day, you have to keep up with that stuff. You're ultimately responsible for the codebase in a way that junior/mid devs are not and if you don't understand large aspects of how it works you can't be effective. It doesn't help that people who stagnate like this usually weren't very good at/engaged with their jobs to begin with. They're usually senior in name only, where their managers know not to actually assign them stuff that matters.
gabereiser 6y ago
For sake of argument though, can we assume all “old” programmers in this case are ones that have been doing this a long time and are actually competent? I’m not disagreeing with you, but I know those are in the minority of us “old” programmers. “Old” vs “Young” can be a measure of experience.
ticmasta 6y ago
There's also old with lots of experience but it's 20 years of doing the same thing, or 10 x 2 years experience vs. 20 years of xp
- otagekki 6y ago
  If the current trend in the software engineering market continues, in 2040 we'll most likely have much more profiles with 10x2 years or 20x1 year than 1x20 years. I have the impression that really few companies value the latter nowadays.
908B64B197 6y ago
I've also seen seniors having 10 times one year of experience as opposed to having 10 years of experience!
dllthomas 6y ago
We should distinguish age from experience from skill. That said, want to call out that experience in other fields can sometimes be tremendously valuable! (... but isn't guaranteed to be)

Juliate 6y ago

Actually, they should be judged by what they can and do contribute to the team, whatever that is. Skills is a subset of that.

virgilp 6y ago
This (and original) statement(s) are all good and nice, but meaningless (in the same way as "there should be no hunger in the world because we have enough food"). Ok, we should judge people by what they can and do contribute to the team. The billion-dollar question is, HOW? Humans are extremely skilled optimizers - give them an objective metric and they'll game it for maximum benefit; make it subjective and it can be better or worse - but in either case, you'll no longer have any agreement on "what they contribute to the team".
- austincheney 6y ago
  > HOW? * Documentation - Can they write? * Potential - Can they provide original solutions to problems? Do they need hand holding? * Initiative - Do they need a signal from a starting gun or are they self-entertained with word products for the team? These are all identifiable maxims.
  - virgilp 6y ago
    I'm not saying "people can't be managed" and "one can't evaluate the performance of a programmer" - that'd be obviously false. What I _am_ saying is that it's an art not a science - very hard to teach, impossible to scale. Take your example with "Documentation" - if you measure anything objective (words written, number of functions/features that have associated documentation) and tie it with the performance evaluation, those metrics will soon become meaningless.
    - athenot 6y ago
      Poor metrics are meaningless regardless of what you try to measure. In the example of documentation a better metric might be a composite value of (i) how many wiki articles a developer has written, weighed 0.33 and (ii) how useful on a numerical scale his/her peers rate the documentation produced, weighed 0.67. This is just an example but it's a composite of perceptual and objective, with the perceptual being a lot more important (and to prevent gaming the system by writting lots of useless articles).
      - virgilp 6y ago
        It's all in the details. If I get to pick who rates "how useful", this translates into a general "how well liked by my colleagues am I" (general problem with 360* feedback; I'm not saying it's useless, but it does have its limitations)
      - tstrimple 6y ago
        The way I've experienced it is that when a measurement becomes a metric, it ceases to be a good measurement. When people's bonus is tied to a measurement, they will find creative ways to influence that measurement which, in many cases, defeats the purpose of what it was trying to measure in the first place. It's not simply a matter of choosing the right measurements. It's also a matter of how you incentivize those measurements. When I worked at Microsoft one of the teams I was adjacent to had a metric on number of new apps in the Windows Phone app store. So the teams went out and got a bunch of college students to build shitty apps in bootcamp style working groups. Suddenly the number of apps isn't good enough, so they added review metrics. Now those teams add a "let's all rate each other's apps" portion to the bootcamp taking you even further away from the results you're trying to obtain.
    - brlewis 6y ago
      If it's true that one can evaluate the performance of a programmer, what does that mean? Can it be reduced to a vector of scalar values? I hate doing performance reviews, and I especially didn't like when at a former employer I was asked to stack rank programmers. I feel like it's a task that's so difficult to get right, I can't even think of a wrong way to do it that's useful.
  - rezeroed 6y ago
    Re initiative. I've had jobs which did not want initiative on a macro level - my manager would tell me what was wanted, I'd go away and make it happen. Those managers loved me. My current role, bullshitted into a "devops" role, I'm expected to spend my days showing initiative - building things that I think will be useful - and which never get used. I'll take the former jobs. What I have now sounds like freedom, it feels pointless and torturously demotivating. Do my managers know what they're doing? Do they have any roadmap? Can they see shortcomings in our systems? Is it mushroom management or cluelessness? I think these positive sounding words eg "initiative" are not positive - they are context dependent. "Potential" - if you need someone writing endless crud, if they have potential are they going to stick around? Do you really want/need Achilles? Are you really leading the Trojan army? Maybe you just need sticky tape, not a welding torch.
    - virgilp 6y ago
      You touch on two issues here: one, that there's an entire gamut and not a binary "senior/junior"... and management just LOVE to present requirements like "Can walk on liquid water; God asks him for advice on how to run the world" when you ask "what do I need to do in order to get to next level", especially in big corporations [1]. The second is that different types of people prefer different styles of working and sometimes forget there is another side (multiple "other sides", really). A team needs to be a mix of capabilities and personalities to be successful - a team of 100 identical individuals would likely fail, even if all them are Peter Norvig). So, you need people that are "senior" in the sense that "knows the business well enough to provide different perspectives" (and for those "shows initiative" is critical) but you also need specialists where "senior" means "knows technology X really really well". Say, a DBA - can keep your database up, can write efficient queries to retrieve information that you want; but doesn't know sh*t about what information would be interesting to retrieve. Or whether it's a good idea to keep some information X in the database, considering the various business, legal, social, cost perspectives. > Do my managers know what they're doing? Here's the thing: I believe nobody _really_ does. Sure, some know more than others, but in absolute terms, we're all basically guessing. That's why people insist on engineers that "show initiative" - not because they're always right, but in an environment where we don't _really_ know what we're doing, people yelling different perspectives are valuable. However, as mentioned above - not all senior engineers want or are inclined to show this kind of initiative; and it's unfair to penalize those kinds of engineers, because we _need_ the different types of personalities. [1] FWIW I believe the reality is , always, that you need to (A) work on a successful project; and (B) be generally liked by your colleagues and maybe managers. For very senior titles, also (C) have a large network of connections within the company - i.e. work on many things, or on one thing but a thing that is used by many teams/ really popular)
- Juliate 6y ago
  How? Work with them. Pay them enough as they don't have to think about it. Objective metrics are good if you think you can measure accurately for all individuals at the macro level. You may not need that (I mean, really _need_ it for your business to function, unless you're in the metric-tracking business). If your teams have distinct and articulate enough outputs, you can retribute each team according to its specific outputs. At the macro level, you don't need to have more details (but you still may ask). Let the team manage its own distribution of the retribution - and so on (so you do need trained managers to do it appropriately at each level).
maratumba 6y ago
That's a better way of putting it.

gtsop 6y ago

> There is an assumption that "old" means "experienced" which is not necessarily true. Agreed > They should be judged by their skills, the same way the young ones are being judged. Disagree, but this is my subjective opinion. Old people in general are not able to keep up with young people for many reasons. My personal stance is we shouldn't compare them as equals, but rather try to get the most out of everyone. The baseline for judging someone (to be hired or to stay in a job) should depend on the effort they put in. Actual performance should be taken into account when deciding on promotions and bonuses. This would create an environment safe for old people to keep their jobs until they retire, but also fair to people of any age to get higher salaries and roles based on their skills.

maratumba 6y ago
Treating people differently based on the class they belong in, in this case age, is the definition of discrimination.
- gtsop 6y ago
  Firstly I am all in for discrimination that results in positive effects for people in need (as long as it is reasonable and not blind benefits for the sake of suposedly helping minorities) However, my solution does not judge people differently based on age. It judges everyone in a way that allows old people to fairly compete with young people on the basis of effort put in rather than pure skills/performance output.
  - reflectiv 6y ago
    We are talking about technical abilities...if you discriminate outside of that, including age, I would whole heartedly call that the bad kind of discrimination.
    - gtsop 6y ago
      I am really not sure why my point isn't clear. I am not judging people differently based on age. I observe that skills/performance is not a fair metric for old people to compare against young ones. Thus, in order to create a field of fair competition I argue that for the baseline desicisons (getting and keeping a job) people of all ages should be judged on the effort they put in, a fair metric for all ages. Then comes the second layer of judgement based on skills which decides who gets promoted or gets performance bonuses. Old people would have less chances to win in this layer of judgement but at least they can keep their jobs safe as long as they put in effort.

SteveMoody73 6y ago

I agree that age doesn't mean experience. I work in a company with a small development team and we're all around the same age group with no young programmers. In thios group we have a programmer in his early 40s, who has been programming for years, that I would still consider a "junior" programmer. He can usually perform a task but needs more guidance and checking than the other members if the team, most of which have been there time. On the other side we also had a developer work there a few years back that was in his late 50s and wrote some of the worse looking code I've ever seen. Fortunatly he didn't last long and none of his code is running in production.

auggierose 6y ago
What exactly is the meaning of "On the other side" here?
- JustResign 6y ago
  I believe the best equivalent phrase would be "on the other hand" or "in contrast"
Nursie 6y ago
I've met those guys. The 50-something who had been in the same role 37 years, who was laid off and when hired into a new company, just couldn't adapt. The 40-something who's fine to do maintenance and the odd enhancement, but you wouldn't trust to do a major refactor or a large chunk of green-field. Some people just aren't as able, find themselves a comfort zone and stick to it. So even experience doesn't necessarily mean experience :) (This isn't to say such people aren't useful, that's a different measure.)

skohan 6y ago

Yes it's not about valuing age, but it is about valuing experience. Sometimes raw talent and problem solving ability is the most important quality to look for, but sometimes experience in the field is incredibly relevant and valuable, and can't be replaced by raw talent.

jondubois 6y ago
If you're young, you fit in a narrow spectrum of experience with a relatively low upper bound. If you're old, then the spectrum of possible experience is much broader. You could range from being totally inexperienced to being extremely experienced. Also, as I get older, I realize that talent plays a significant part (which is independent of age). But there is a huge problem that almost all companies don't know how to identify technical talent; they focus on the wrong attributes like ability to perform under pressure and ability to recall details. Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly; that is the real valuable talent.
- Loughla 6y ago
  >Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly So, from my non-tech perspective, that's just every single job at every single employer. Any position I've had that has been in charge of hiring people - I am acutely aware that I can teach the position. I can teach the technical aspects and detail knowledge of how to do a job. What I can't teach is the ability to prioritize, critically think, and communicate appropriately. Those are real talents. I guess what I'm saying is - tech companies are garbage at evaluating for those things, because (I would argue) all/nearly all companies are garbage at evaluating for those things. It doesn't matter if it's a tech company, garbage company, or insurance company - they're all (again, my experience) equally garbage at finding those skills in people through their standard interview processes. If you figure out how to implement a standard interview process to evaluate for the three things you list, you will be the world's first trillionaire.
- skohan 6y ago

Consultant32452 6y ago

Some people have 10 years of experience. Other people have 1 year of experience 10 times.

nullsense 6y ago
And some people have 10 years of just not very useful experience. Not the same year 10 times but 10 discrete, non-overlapping years.
collyw 6y ago
Ten years of experience in one tech stack will give you mastery. 1 year changes with a new language / framework / tools every time will mean you are forever a novice.
- bdcravens 6y ago
  Ten years of experience in one tech stack that has fallen by the wayside means you're outclassed by the developer with 2 years of relevant experience.
- ivalm 6y ago
  If you know 10 different tech stacks you probably have immense breadth and can learn/do new things easily. That’s is incredibly valuable. There is a massive difference when you are learning a new stack for 11th time vs 2nd or 3rd time. Sometimes you need people with deep mastery of some specific, sometimes you need people who have seen everything, can learn anything, and synthesize a broad view.
  - tartoran 6y ago
    That is not entirely true. After learning the n-th stack and knowing the knowledge will likely sputter out in a couple of years cycles, one is likely to learn enough to get done what needs to be done. As someone points out, few out there are true experts if they're constantly learning a new stack. And also people who want to learn all the time do get bored of learning the same thing, a lot of them branch out in different directions that are a lot less shapeshifting. Ideally I preferred learning the technology for a few years then steeping back and reaping the benefits and do stuff with it. But, there is a fear that not keeping up leads to obsolescence on the job market so we're in this constant cycle of learning new things with diminishing returns

dimmke 6y ago

I agree with this. I've known some people who've been coding for 15-20 years who just coast, and end up in senior positions because of how long they've been employed when their skills are really at the level of a 2 year junior. It's even worse in front-end, because that means their skills are that of a 2 year junior 10 years ago, they don't have any of the skills with new frameworks and techniques. If you want sloppy bootstrap laden html/css and jQuery, they're your person though.

collyw 6y ago
Out of interest what skills are you talking about? I am an old fart by IT standards and i have come to realise that being able to come up with an algorithm randomly is not such a useful skill considering how infrequently we actually have to do it. Being able to say "no" and getting on with other developers are far more valuable than being able to solve a soduku puzzle once you have acquired a certain level of knowledge. After that it should be about managing complexity.
- akiselev 6y ago
  Not the OP but I largely look for experience with CI/CD workflows and release management, unit/integration/systems testing that doesn't cripple R&D, QA, distributed systems beyond a webserver & DB, and just general "philosophy of software engineering" type stuff like an understanding of the factors that led to the evolution from monolith to microservice, agile/scrum/management fad of the week, and how to make tech tradeoffs based on business goals. These are largely soft skills, not algorithmic trivia. Unfortunately, there's no one size fits all worksheet for those soft skills that HR can hand out to interviewers, so everyone gets lazy and falls back to the whiteboard BS.
- dimmke 6y ago
  >i have come to realise that being able to come up with an algorithm randomly is not such a useful skill considering how infrequently we actually have to do it. This isn't what I'm talking about - I'm talking domain specific skill. If you're a frontend developer for instance, you should understand the new language features of JavaScript that came out in 2015-2016 and be able to use them. You should know how to use flexbox for CSS instead of floats for layout (IMO) If you're a senior developer still writing code every day, you have to keep up with that stuff. You're ultimately responsible for the codebase in a way that junior/mid devs are not and if you don't understand large aspects of how it works you can't be effective. It doesn't help that people who stagnate like this usually weren't very good at/engaged with their jobs to begin with. They're usually senior in name only, where their managers know not to actually assign them stuff that matters.

gabereiser 6y ago

For sake of argument though, can we assume all “old” programmers in this case are ones that have been doing this a long time and are actually competent? I’m not disagreeing with you, but I know those are in the minority of us “old” programmers. “Old” vs “Young” can be a measure of experience.

ticmasta 6y ago

There's also old with lots of experience but it's 20 years of doing the same thing, or 10 x 2 years experience vs. 20 years of xp

otagekki 6y ago
If the current trend in the software engineering market continues, in 2040 we'll most likely have much more profiles with 10x2 years or 20x1 year than 1x20 years. I have the impression that really few companies value the latter nowadays.

908B64B197 6y ago

I've also seen seniors having 10 times one year of experience as opposed to having 10 years of experience!

dllthomas 6y ago

We should distinguish age from experience from skill. That said, want to call out that experience in other fields can sometimes be tremendously valuable! (... but isn't guaranteed to be)