8 ms·

I am not really "old" (ie over 40), but I have interviewed older candidates for some technical roles at very different companies, and I've found there are eithe

I am not really "old" (ie over 40), but I have interviewed older candidates for some technical roles at very different companies, and I've found there are either old people who believe they know better at everything whose skills have not improved much since their early 30s, and then old people who stay up to date on technologies, trends, and realize that programming is a field you never really ever master with time or age; it shifts too much to be able to ever fully grasp it. The "old" people who are curmudgeonly and stuck on older technical stacks are the ones who don't fare well. The ones who are current in skillset never seem to have an issue and generally impress the people they meet, as they bring both experience and current technical knowledge to the table. Anecdotally, I would say 8/10 of the 40+ crowd I have interviewed fall into the "old technical stack" / "i know better" crowd, and I think these are the ones that poison the well for the good guys. I am beginning to believe that the trick to software engineering as a career vs. management is to stay current above all else. If you let yourself become obsolesced, you will be thrown aside like an old PowerBook. That's the reality of the technology industry and has little to do with age.

blazespin 10y ago
Yeah, for the vast majority of engineering programming is like selling shoes. You just need about 4 years experience and you pretty much know it all. Certain skill sets are great for older folks though. Security, for example. You want to work with someone who has a long track record of being trustworthy. That being said, there is something compelling about an older engineer who constantly re-invents himself with the latest technology.
- micaksica 10y ago
  > Yeah, for the vast majority of engineering programming is like selling shoes. You just need about 4 years experience and you pretty much know it all. That's the point I'm trying not to make. Are you building a startup that's effectively a CRUD app? If so, sure, that's pretty much all you need and is why coder schools have become so prevalent - they get you to a practicing point that covers the bases of most small websites and very, very basic startups. Age and experience brings with it something vital: the ability to build long term pattern recognition of technology business cycles, the "all is old is new again", the ways that novel technologies may fall like their predecessors. This is not something you learn in a CS program or even a few years out of college. It's something you only learn by playing with tens of languages and mastering six or seven over decades, by constantly learning, by being part of those business cycles. This skillset is often discredited and is enormously valuable, but I believe it requires a tireless passion for novelty and modern technique to become a multiplier on skill.
  - AstralStorm 10y ago
    Experience is more important if you are actually developing algorithms rather that making another app. It takes time and practice of genius to get a handle on required mathematics for AI, adaptive systems or advanced data structures. It is no accident that mathematicians are divided into super young genius and old bearded wizard camps.
  - GarvielLoken 10y ago
    I disagree with "This is not something you learn in a CS program". Anyone who has taken a SICP course will know "all is old is new again". But in large I agree with you.
- tigershark 10y ago
  You will never "know it all" about programming. If you seriously think then you can learn all in 4 years I'm really wondering what kind of things are you working on.
  - collyw 10y ago
    Node, Mongo and Angular would be my bet.
- throwanem 10y ago
  > You just need about 4 years experience and you pretty much know it all. No. After four years you know just about enough to inflict a really nasty case of the second-system effect on some unsuspecting customer.
- tbenbrahim 10y ago
  I have been programming for 30 years. I can look at code that is 10 years old and see how much I have improved in those 10 years. 26 year old code? It was a joke. I thought I knew it all back then, but for about the last 20 years, I have been working with the realization that I know less than 10% about this field. Your statement cannot be true unless you only work in the very limited scope of CRUD apps. Even then, you probably still have a lot to learn about SQL optimization (I know, you use an ORM and do not worry about those pesky details:<) I am continuously amazed by the poor quality or performance of a lot of commercial software, probably borne out of hiring practices that espouse the same belief you do.
- collyw 10y ago
  There is a difference between being able to write code and being able to write nice maintainable code that is easy for others to understand. It took me a lot longer than 4 years to reach the second stage.
- minipci1321 10y ago
  (Could guess that one will provoke reactions ;-)) My biggest to date (but not the only one): having received complaints, I figured in 2 days that the culprit is the change in the manufacturing-workweek-number of the DDR ICs. It took them several months onsite with people travelling from abroad and with expensive equipment to find the real root cause, and guess what they have found? And I am not even a hardware engineer. How did I do that? Intuition. You need lots of time to develop intuition, much more than 4 years, and once you got it, it saves lots of time and money. I have also seen other experienced engineers do this sort of tricks, and I pity the workplaces where people aren't familiar with this.
marklgr 10y ago
This is true for all ages and categories; there are good and bad younger programmers, good and bad middle-aged managers, good and bad grey beard *nix sysadmins etc.
- micaksica 10y ago
  Oh, I agree. I think there is a definite issue of people ascribing "old dogs, old tricks", and that bias is the hard thing to overcome. It's especially hard when a lot of people are confirming that. It's the age equivalent of https://xkcd.com/385/ https://xkcd.com/385/ . When it's a younger person, it's "this person can't code for <x> because they don't have experience." It's harder to quell that cognitive dissonance when you don't have that out and forces you to place the blame on incompetence.
  - narag 10y ago
    There's also a definite issue of people ascribing "every older time was worse".
flukus 10y ago
The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance. Lately I've been taking a look at a lot of older tools and being pleasantly surprised by how capable they are compared to modern ones. I started coding professionally in a world of virtual machines and xml files, now where moving back to native compilations and json. Eventually we'll rediscover ini files and how there even simpler than json and we can avoid the curly bracket tax. I've used every build tool under the sun but recently discovered that make was simpler and better than anything else I've used. We've gone full circle on ORM's and now writing sql is in vogue again. I wish I'd learned more from those guys much earlier.
- PhasmaFelis 10y ago
  We're so eager to justify arbitrary technical fads. Use something until you have enough experience to start seeing its flaws, move on to something shiny and new and perfect until you've used it long enough to see its flaws, repeat.
  - flukus 10y ago
    > Use something until you have enough experience to start seeing its flaws I think we've been completely skipping this step for the last few years.
    - gaius 10y ago
      You can very easily find yourself in a situation where every project is either your first in technology X, or trying to maintain something that was someone else's first attempt at using it. "Legacy" means "proven in production and making the company money" but too often these days it is seen as a dirty word.
- lsc 10y ago
  > The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance. This is actually one of my biggest career problems. I mean, it's an advantage, too... I can pretty quickly understand new things, because they are similar to old things, but... on an emotional level part of me rebels from the new cool thing simply because the old thing worked, often more reliably, and this new thing? this new thing has a bunch of little subtle differences and bugs that I have to learn and deal with and fix, just like the old thing had a decade ago, so my natural reaction to the latest fad is usually a negative emotional response, and pointing out that it's essentially the same thing as the old thing. This causes obvious problems, of course, with the people who got promoted for "demonstrating complexity" when they wrote or implemented the new system. I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!) >They aren't interested in the cloud because it's modern day mainframes for instance. This is the opposite of true. Mainframes were all about complete reliability; you can always rely on the hardware, or at least that's what you are paying for. "The cloud" is all about the chaos monkey, about writing your application to deal with any server failing (or returning nonsense) at any time. The disillusionment with "the cloud" comes from having to deal with managers who think that "the cloud" means reliability, when it really means "write your applications so they can deal with hardware that is significantly less reliable than hardware managed by in-house sysadmins"
jasonkester 10y ago
Thinking about it, I find that I straddle the line on this. I'm up to date on the New Shiny and will happily run with whatever flavor of the month language, framework, and programming paradigm that a given gig wants. Yeah, sure, Node.js with tons of functional stuff mixed in pulling from a NoSQL store and React on the front end. I'm your guy. We're gonna change the world! But for my own stuff, there's no way I'd use any of that crap. Good old C#, SQL Server and a proper boring stack and tool set that I know won't just up and fall over on a Saturday morning and leave me debugging NPM dependencies all weekend instead of bouldering in the forest with the kids. This stuff is my proper income stream, and the most important thing is that it works. If that means I have to write a "for" loop and declare variables and risk 19 year old kids snooting down at my code, so be it. But yeah, the key is to never get so far down in to that comfy hole that you can't hop back into the present day when it's time to talk shop with the cool kids.
- lj3 10y ago
  What do you use for frontend development then? Raw JS? Jquery? Flash? :)
  - jasonkester 10y ago
    Yeah, mostly just javascript, with the occasional bit of jquery thrown in. Like I say, I've been quite deep in to various front end frameworks and scripting libraries and learned what is useful and what to avoid. Turns out you can get a lot done when you don't have to constantly fight with terrible 3rd party javascript.
YeGoblynQueenne 10y ago
>> If you let yourself become obsolesced, you will be thrown aside like an old PowerBook. There are many large companies (mainly, banks and card corps) paying really, really good salaries for people with 30+ years experience with COBOL, JCL, REXX and the like. You know, mainframe stuff. Obsolescence is in the eye of the adolescent, if I may be so bold.
- uhhuhuh 10y ago
  You know, I always heard this, and I have kind of a morbid fascination with old mainframe technologies, even though I've never used any professionally. So I looked pretty deeply into that job scene. Turns out the vast majority of the jobs hiring for COBOL etc pay 70,000 to 80,000 a year. It's not bad pay in some parts of the country, and the hours are generally reasonable. But they're not really, really good salaries.
  - dozzie 10y ago
    It pays sensibly because it's a job that really needs to be done, but it doesn't pay too well because it's not a rocket science and it's easy to find somebody who can be trained to do it.
  - YeGoblynQueenne 10y ago
    I worked in one of those roles for a year or so, though in the UK. From the salaries you quote, I assume you mean the US? In the UK that sort of money is quite good. The salary you quote, converted to UK money, is about right for entry-level roles. I was hired in that company at a graduate level and I had no experience of mainframes whatsoever when I got the job (which I hunted down out of the same morbid fascination you mention). My older colleagues though, the ones with 30+ years experience, they would be getting much better money than that. It would depend on the position also, but I heard of at least one graybeard who was asked back from retirement, because the company couldn't afford to lose his expertise. Now, I don't know what they paid him, but I'm pretty sure it's what I call a really, really good salary.
ap22213 10y ago
Making generalizations from a set of interviewees is very risky - because interviewees are very, very different from the general population. I should know because I recently made this same error. Background: Current company recently got series B, and I'm trying to aggressively scale the engineering team. As such, I've been rapidly phone screening candidates at a much higher volume than usual. After screening the first set, I began feeling very sad about the current state of software engineering. The average age was probably about 27. All had CS degrees. All were experienced Java developers. And, yet most did not know the difference between a long and an int. Most couldn't describe the differences between linked lists, arrays, and hash tables. Most could not explain how to make a block of code thread safe. Most could not describe how an interface is different from a class. Most could not explain the difference between value passing and reference passing. I was so aghast. I mentioned in passing to a co-worker that computer science degrees must have become so dumbed down over the last decade. But, then I realized my mistake. Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample.
- acdha 10y ago
  > Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample. Another thing I've seen many times is that the listing either wasn't written well, circulated in the right communities, or that details like compensation or the environment scared off people with better options. That can be a very delicate subject to bring up because many places don't want to admit that the problem could be their business rather than the candidate pool.
  - ap22213 10y ago
    Yep - odds are so low to find someone decent. Let's say you're a good, experienced developer. You get 10 recruiter messages per week. You ignore most of them but 1 in 20 you decide to read. There's a 10% chance that the description looks like a good fit. You contact the recruiter and tell them your salary requirements. There's a 15% chance that it's in your range. You decide to set up a phone screen. But, since you're valuable to your current company, you're extremely busy. There's a 20% chance that you can make the call. I'm too lazy to calculate that, but that's a huge number of people to contact just to phone screen one good person.
mikekchar 10y ago
Code is code and stacks are irrelevant. As other commenters have said, curmudgeonly old guys say, "I know better" and quite a few of them do ;-). But I think get get your point. The other day, a promising young programmer asked me how to deal with the overwhelming load of new frameworks. Which ones should he learn? Which ones should he ignore? What should he do if he picks the wrong one? How will he know? In my opinion, it really doesn't matter as long as he is learning something new. You only get stuck when you try to stick to the things you are familiar with. You need to keep stretching yourself time after time. If someone says to me, "Do it in Python", "Do it in Elixir", "Do it in Haskell", "Do it in Go"... it just doesn't matter to me. I've been through that blender before a hundred times. In fact, that's precisely why you would pick a guy like me. I'm not trying to keep up with the current trends. That doesn't matter. But I'm also trying not to hang on with a death grip to what little I know. On the other hand, if you need some guy who knows every single detail of how Rails works, hire a young guy who has only ever worked with Rails before. You need a mix on a team. Pair him up with an old guy so that he gets some perspective before he burns out his career.
- pjc50 10y ago
  > curmudgeonly old guys say, "I know better" and quite a few of them do Oh, absolutely, we often do. But, like the ancient kungfu master trope, you can't tell your juniors this directly, it's a realisation they have to reach themselves. Sometimes while being smacked in the face by the consequences of not listening. (More seriously, being a curmudgeon doesn't help; being a mentor does)
br3w5 10y ago
So really age doesn't matter - experience and aptitude does. Here's your quote minus references to age. "I've found there are either people who believe they know better at everything whose skills have not improved much, and then people who stay up to date on technologies, trends, and realize that programming is a field you never really ever master with time"
mark_l_watson 10y ago
+1 Exactly right. I am in my 60s and I have a satisfying consulting business, occasionally being an employee, but mostly consulting over the last several decades. My formula is to spend at least 15 hours a week on non-billable learning projects, writing technical books, etc. A lot of this time is simply reading papers in my areas of interest (deep learning, functional languages like Haskell, application of deep learning to NLP, etc.) and writing enough code to make sure I understand new technologies. I get hired because I stay current.
- lj3 10y ago
  It sounds like your idea of staying current is different from what others are talking about in this thread. Do you keep up with the latest JS frameworks and nodejs? Rails? There's a distinction to be made between learning new things that are actually useful (deep learning, NLP, new programming paradigms) instead of learning the latest framework just to do something we could already do with another technology 5-10 years ago.
  - mark_l_watson 10y ago
    When I used Rails (a long time ago) and Node.js (last year) for work, then yes I did get up to speed on both of them and enjoyed it. I agree that core technologies like linear algebra, machine learning, etc. aren't the current topic. The main thing is to learn new things, and as someone else here said, maybe it does not matter so much what you learn as long as you learn new things.
maxxxxx 10y ago
My observation is that most devs get stuck in their favorite stack no matter what their age is. A lot of younger guys I talk to are stuck on node.js or whatever is cool right now and can't be bothered to consider alternatives either. I think there is just a large percentage of people in tech that do it to make an income with the least amount of thinking. Only a small percentage is really interested in the technology.

blazespin 10y ago

Yeah, for the vast majority of engineering programming is like selling shoes. You just need about 4 years experience and you pretty much know it all. Certain skill sets are great for older folks though. Security, for example. You want to work with someone who has a long track record of being trustworthy. That being said, there is something compelling about an older engineer who constantly re-invents himself with the latest technology.

micaksica 10y ago
> Yeah, for the vast majority of engineering programming is like selling shoes. You just need about 4 years experience and you pretty much know it all. That's the point I'm trying not to make. Are you building a startup that's effectively a CRUD app? If so, sure, that's pretty much all you need and is why coder schools have become so prevalent - they get you to a practicing point that covers the bases of most small websites and very, very basic startups. Age and experience brings with it something vital: the ability to build long term pattern recognition of technology business cycles, the "all is old is new again", the ways that novel technologies may fall like their predecessors. This is not something you learn in a CS program or even a few years out of college. It's something you only learn by playing with tens of languages and mastering six or seven over decades, by constantly learning, by being part of those business cycles. This skillset is often discredited and is enormously valuable, but I believe it requires a tireless passion for novelty and modern technique to become a multiplier on skill.
- AstralStorm 10y ago
  Experience is more important if you are actually developing algorithms rather that making another app. It takes time and practice of genius to get a handle on required mathematics for AI, adaptive systems or advanced data structures. It is no accident that mathematicians are divided into super young genius and old bearded wizard camps.
- GarvielLoken 10y ago
  I disagree with "This is not something you learn in a CS program". Anyone who has taken a SICP course will know "all is old is new again". But in large I agree with you.
tigershark 10y ago
You will never "know it all" about programming. If you seriously think then you can learn all in 4 years I'm really wondering what kind of things are you working on.
- collyw 10y ago
  Node, Mongo and Angular would be my bet.
throwanem 10y ago
> You just need about 4 years experience and you pretty much know it all. No. After four years you know just about enough to inflict a really nasty case of the second-system effect on some unsuspecting customer.
tbenbrahim 10y ago
I have been programming for 30 years. I can look at code that is 10 years old and see how much I have improved in those 10 years. 26 year old code? It was a joke. I thought I knew it all back then, but for about the last 20 years, I have been working with the realization that I know less than 10% about this field. Your statement cannot be true unless you only work in the very limited scope of CRUD apps. Even then, you probably still have a lot to learn about SQL optimization (I know, you use an ORM and do not worry about those pesky details:<) I am continuously amazed by the poor quality or performance of a lot of commercial software, probably borne out of hiring practices that espouse the same belief you do.
collyw 10y ago
There is a difference between being able to write code and being able to write nice maintainable code that is easy for others to understand. It took me a lot longer than 4 years to reach the second stage.
minipci1321 10y ago
(Could guess that one will provoke reactions ;-)) My biggest to date (but not the only one): having received complaints, I figured in 2 days that the culprit is the change in the manufacturing-workweek-number of the DDR ICs. It took them several months onsite with people travelling from abroad and with expensive equipment to find the real root cause, and guess what they have found? And I am not even a hardware engineer. How did I do that? Intuition. You need lots of time to develop intuition, much more than 4 years, and once you got it, it saves lots of time and money. I have also seen other experienced engineers do this sort of tricks, and I pity the workplaces where people aren't familiar with this.

marklgr 10y ago

This is true for all ages and categories; there are good and bad younger programmers, good and bad middle-aged managers, good and bad grey beard *nix sysadmins etc.

micaksica 10y ago
Oh, I agree. I think there is a definite issue of people ascribing "old dogs, old tricks", and that bias is the hard thing to overcome. It's especially hard when a lot of people are confirming that. It's the age equivalent of https://xkcd.com/385/ https://xkcd.com/385/ . When it's a younger person, it's "this person can't code for <x> because they don't have experience." It's harder to quell that cognitive dissonance when you don't have that out and forces you to place the blame on incompetence.
- narag 10y ago
  There's also a definite issue of people ascribing "every older time was worse".

flukus 10y ago

The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance. Lately I've been taking a look at a lot of older tools and being pleasantly surprised by how capable they are compared to modern ones. I started coding professionally in a world of virtual machines and xml files, now where moving back to native compilations and json. Eventually we'll rediscover ini files and how there even simpler than json and we can avoid the curly bracket tax. I've used every build tool under the sun but recently discovered that make was simpler and better than anything else I've used. We've gone full circle on ORM's and now writing sql is in vogue again. I wish I'd learned more from those guys much earlier.

PhasmaFelis 10y ago
We're so eager to justify arbitrary technical fads. Use something until you have enough experience to start seeing its flaws, move on to something shiny and new and perfect until you've used it long enough to see its flaws, repeat.
- flukus 10y ago
  > Use something until you have enough experience to start seeing its flaws I think we've been completely skipping this step for the last few years.
  - gaius 10y ago
    You can very easily find yourself in a situation where every project is either your first in technology X, or trying to maintain something that was someone else's first attempt at using it. "Legacy" means "proven in production and making the company money" but too often these days it is seen as a dirty word.
lsc 10y ago
> The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance. This is actually one of my biggest career problems. I mean, it's an advantage, too... I can pretty quickly understand new things, because they are similar to old things, but... on an emotional level part of me rebels from the new cool thing simply because the old thing worked, often more reliably, and this new thing? this new thing has a bunch of little subtle differences and bugs that I have to learn and deal with and fix, just like the old thing had a decade ago, so my natural reaction to the latest fad is usually a negative emotional response, and pointing out that it's essentially the same thing as the old thing. This causes obvious problems, of course, with the people who got promoted for "demonstrating complexity" when they wrote or implemented the new system. I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!) >They aren't interested in the cloud because it's modern day mainframes for instance. This is the opposite of true. Mainframes were all about complete reliability; you can always rely on the hardware, or at least that's what you are paying for. "The cloud" is all about the chaos monkey, about writing your application to deal with any server failing (or returning nonsense) at any time. The disillusionment with "the cloud" comes from having to deal with managers who think that "the cloud" means reliability, when it really means "write your applications so they can deal with hardware that is significantly less reliable than hardware managed by in-house sysadmins"

jasonkester 10y ago

Thinking about it, I find that I straddle the line on this. I'm up to date on the New Shiny and will happily run with whatever flavor of the month language, framework, and programming paradigm that a given gig wants. Yeah, sure, Node.js with tons of functional stuff mixed in pulling from a NoSQL store and React on the front end. I'm your guy. We're gonna change the world! But for my own stuff, there's no way I'd use any of that crap. Good old C#, SQL Server and a proper boring stack and tool set that I know won't just up and fall over on a Saturday morning and leave me debugging NPM dependencies all weekend instead of bouldering in the forest with the kids. This stuff is my proper income stream, and the most important thing is that it works. If that means I have to write a "for" loop and declare variables and risk 19 year old kids snooting down at my code, so be it. But yeah, the key is to never get so far down in to that comfy hole that you can't hop back into the present day when it's time to talk shop with the cool kids.

lj3 10y ago
What do you use for frontend development then? Raw JS? Jquery? Flash? :)
- jasonkester 10y ago
  Yeah, mostly just javascript, with the occasional bit of jquery thrown in. Like I say, I've been quite deep in to various front end frameworks and scripting libraries and learned what is useful and what to avoid. Turns out you can get a lot done when you don't have to constantly fight with terrible 3rd party javascript.

YeGoblynQueenne 10y ago

>> If you let yourself become obsolesced, you will be thrown aside like an old PowerBook. There are many large companies (mainly, banks and card corps) paying really, really good salaries for people with 30+ years experience with COBOL, JCL, REXX and the like. You know, mainframe stuff. Obsolescence is in the eye of the adolescent, if I may be so bold.

uhhuhuh 10y ago
You know, I always heard this, and I have kind of a morbid fascination with old mainframe technologies, even though I've never used any professionally. So I looked pretty deeply into that job scene. Turns out the vast majority of the jobs hiring for COBOL etc pay 70,000 to 80,000 a year. It's not bad pay in some parts of the country, and the hours are generally reasonable. But they're not really, really good salaries.
- dozzie 10y ago
  It pays sensibly because it's a job that really needs to be done, but it doesn't pay too well because it's not a rocket science and it's easy to find somebody who can be trained to do it.
- YeGoblynQueenne 10y ago
  I worked in one of those roles for a year or so, though in the UK. From the salaries you quote, I assume you mean the US? In the UK that sort of money is quite good. The salary you quote, converted to UK money, is about right for entry-level roles. I was hired in that company at a graduate level and I had no experience of mainframes whatsoever when I got the job (which I hunted down out of the same morbid fascination you mention). My older colleagues though, the ones with 30+ years experience, they would be getting much better money than that. It would depend on the position also, but I heard of at least one graybeard who was asked back from retirement, because the company couldn't afford to lose his expertise. Now, I don't know what they paid him, but I'm pretty sure it's what I call a really, really good salary.

ap22213 10y ago

Making generalizations from a set of interviewees is very risky - because interviewees are very, very different from the general population. I should know because I recently made this same error. Background: Current company recently got series B, and I'm trying to aggressively scale the engineering team. As such, I've been rapidly phone screening candidates at a much higher volume than usual. After screening the first set, I began feeling very sad about the current state of software engineering. The average age was probably about 27. All had CS degrees. All were experienced Java developers. And, yet most did not know the difference between a long and an int. Most couldn't describe the differences between linked lists, arrays, and hash tables. Most could not explain how to make a block of code thread safe. Most could not describe how an interface is different from a class. Most could not explain the difference between value passing and reference passing. I was so aghast. I mentioned in passing to a co-worker that computer science degrees must have become so dumbed down over the last decade. But, then I realized my mistake. Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample.

acdha 10y ago
> Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample. Another thing I've seen many times is that the listing either wasn't written well, circulated in the right communities, or that details like compensation or the environment scared off people with better options. That can be a very delicate subject to bring up because many places don't want to admit that the problem could be their business rather than the candidate pool.
- ap22213 10y ago
  Yep - odds are so low to find someone decent. Let's say you're a good, experienced developer. You get 10 recruiter messages per week. You ignore most of them but 1 in 20 you decide to read. There's a 10% chance that the description looks like a good fit. You contact the recruiter and tell them your salary requirements. There's a 15% chance that it's in your range. You decide to set up a phone screen. But, since you're valuable to your current company, you're extremely busy. There's a 20% chance that you can make the call. I'm too lazy to calculate that, but that's a huge number of people to contact just to phone screen one good person.

mikekchar 10y ago

Code is code and stacks are irrelevant. As other commenters have said, curmudgeonly old guys say, "I know better" and quite a few of them do ;-). But I think get get your point. The other day, a promising young programmer asked me how to deal with the overwhelming load of new frameworks. Which ones should he learn? Which ones should he ignore? What should he do if he picks the wrong one? How will he know? In my opinion, it really doesn't matter as long as he is learning something new. You only get stuck when you try to stick to the things you are familiar with. You need to keep stretching yourself time after time. If someone says to me, "Do it in Python", "Do it in Elixir", "Do it in Haskell", "Do it in Go"... it just doesn't matter to me. I've been through that blender before a hundred times. In fact, that's precisely why you would pick a guy like me. I'm not trying to keep up with the current trends. That doesn't matter. But I'm also trying not to hang on with a death grip to what little I know. On the other hand, if you need some guy who knows every single detail of how Rails works, hire a young guy who has only ever worked with Rails before. You need a mix on a team. Pair him up with an old guy so that he gets some perspective before he burns out his career.

pjc50 10y ago
> curmudgeonly old guys say, "I know better" and quite a few of them do Oh, absolutely, we often do. But, like the ancient kungfu master trope, you can't tell your juniors this directly, it's a realisation they have to reach themselves. Sometimes while being smacked in the face by the consequences of not listening. (More seriously, being a curmudgeon doesn't help; being a mentor does)

br3w5 10y ago

So really age doesn't matter - experience and aptitude does. Here's your quote minus references to age. "I've found there are either people who believe they know better at everything whose skills have not improved much, and then people who stay up to date on technologies, trends, and realize that programming is a field you never really ever master with time"

mark_l_watson 10y ago

+1 Exactly right. I am in my 60s and I have a satisfying consulting business, occasionally being an employee, but mostly consulting over the last several decades. My formula is to spend at least 15 hours a week on non-billable learning projects, writing technical books, etc. A lot of this time is simply reading papers in my areas of interest (deep learning, functional languages like Haskell, application of deep learning to NLP, etc.) and writing enough code to make sure I understand new technologies. I get hired because I stay current.

lj3 10y ago
It sounds like your idea of staying current is different from what others are talking about in this thread. Do you keep up with the latest JS frameworks and nodejs? Rails? There's a distinction to be made between learning new things that are actually useful (deep learning, NLP, new programming paradigms) instead of learning the latest framework just to do something we could already do with another technology 5-10 years ago.
- mark_l_watson 10y ago
  When I used Rails (a long time ago) and Node.js (last year) for work, then yes I did get up to speed on both of them and enjoyed it. I agree that core technologies like linear algebra, machine learning, etc. aren't the current topic. The main thing is to learn new things, and as someone else here said, maybe it does not matter so much what you learn as long as you learn new things.

maxxxxx 10y ago

My observation is that most devs get stuck in their favorite stack no matter what their age is. A lot of younger guys I talk to are stuck on node.js or whatever is cool right now and can't be bothered to consider alternatives either. I think there is just a large percentage of people in tech that do it to make an income with the least amount of thinking. Only a small percentage is really interested in the technology.