6 ms·

I completely agree with you. I started in this field in 1992. I've seen the coming and goings of many flash-in-the-pan technologies. If you are a dev and are

I completely agree with you. I started in this field in 1992. I've seen the coming and goings of many flash-in-the-pan technologies. If you are a dev and are selling yourself on your skillset, ask yourself, "is this sustainable?" The answer is "no." A fifty-year-old brain simply does not absorb new technologies as fast as a 25-year-old-brain. If your plan is to continually adopt new cutting edge technologies in order to stay marketable, I politely submit you need to rethink your long term plan. As an almost 50-year-old, I promise you that the world is not a gentle place for older devs. Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed. As for me, I jettisoned the "technical skill set" war decades ago. I do not sell myself on my technical skill set. I sell myself as the ultimate generalist. This comes with its own set of problems. However, it has allowed me to age more gracefully in my field, because I do not create the expectation that my primary value-added is code generation.

trump2016 10y ago
Great reply. Interesting how your decision to become a generalist stands in direct opposition to most of the replies to this thread: https://news.ycombinator.com/item?id=13409239 https://news.ycombinator.com/item?id=13409239 Given that you probably have much more experience than many of the people here, I'm going to assume that your advice is more sound than theirs.
- pjc50 10y ago
  The truth is somewhat in the middle, I think. An experienced generalist is a very different prospect to a graduate "generalist" - in some sense, all graduates are generalists because they don't have experience. See the thread the other day about how many people with physics degrees crosstrain into tech and programming. Generalism is insurance, while specialism can be more profitable if the speciality you pick ends up in demand.
  - riprowan 10y ago
    I must add that I have undergraduate and graduate technical degrees and spent from 1983-2005 building lots and lots of apps (I started coding at ~ age 15). So I pursued "generalism" only after being a reasonably qualified (but not specialized) technologist.
jballanc 10y ago
> Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed. I'd like to simultaneously disagree and agree with you. If you were a 50 year old coder 10 years ago, then your only hope of remaining in the tech industry would be to add "Manager" to your job title. If you are a 50 year old coder today, that's still a sound direction to go, but increasingly becoming less necessary. If you'll be a 50 year old coder 10 years from now...I think you'll be ok. Yes, at 50 you almost certainly cannot crank out as much code as you can at 20, but so what? As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. The advantage you have at 50 over someone who is fresh and new at 20 is that you can recognize that there is very little that's happened in the last 30 years that is genuinely new. So, if you are 20, go ahead and spend your weekends on side projects learning the latest frameworks. As you continue to do this over the years and decades, shift to focusing more on patterns. By the time you reach 50, you might only generate half as much code as your younger colleagues, but you should be able to solve problems with a quarter of the code required, still making you twice as efficient as them. When coding was new, code was the only metric by which to measure coders, and non-technical management types would view anyone who generated less code as less valuable. If you're not writing 500 lines of code a day, the argument goes, then you should be managing coders who can. But management and problem solving are not a completely overlapping skill set. Some engineers make good managers, but most do not. Luckily, the more technically inclined individuals that populate the ranks of company management, the more this is being recognized and the more these companies are willing to hire the 50-year-old-coder-who-codes-less-but-solves-more-problems.
- riprowan 10y ago
  > As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. This is precisely my argument as a generalist. I may not write code as fast or even as elegantly as I once did, but I'm much, much better at "seeing around corners" to avoid problems, and I'm much more likely to "build the right thing" due to my very broad but not deep technical base. I do not fall into the trap of "when all you have is a hammer everything looks like a nail." > there is very little that's happened in the last 30 years that is genuinely new This is true, but try to convince your 20something peer group of it. They are all convinced that their technical skills are revolutionary. I studied waterfall systems engineering in 1998. But at the same time they also taught "RAD" iterative waterfall, or the precursor to Agile. I ran with RAD, and made it mine, so I've been doing something very similar to "Agile" for two decades. However, I still think that Gannt charts and top-down planning have value. Showing that shit to the wrong 20something developer is a great way to be excommunicated.
sporkenfang 10y ago
Er, one of the best developers I know is over 50. However, they consciously chose that path instead of tracking into management because they like being a principal engineer where that means they still get to work with code, but also have enough experience to anticipate pitfalls and make considered decisions.
mbrodersen 10y ago
I completely disagree with this. I am also a few years shy of 50 and way ahead compared with 20+ year old self-styled "ninja" developers. They simply don't know what they don't know. They truly believe that they are "experts" or "ninjas" because they have read a few tutorials on the latest soon-to-be-forgotten fashionable language/framework. Or believe that framework/language X is truly something new because a "hello world" web application is easy to write. And then a year later, when things get tough and the realise that the wonder framework/language has limitations, they jump ship to yet another shiny "silver bullet" framework/language that will save them from having to actually learn the hard stuff, allowing themselves to still believe that they are "ninjas". Meanwhile, people who actually know their stuff take over the ruins of their efforts and make it work. Rewriting it step by step to fix it.
- mbrodersen 10y ago
  And how do I know this by the way? Because I have done it many many times in my career. Taking over a ruin build by "ninjas" and making it actually work and bug free in production. Meanwhile the "ninjas" have jumped ship to another company, building a new ruin with some new "better" framework/language. Until of course things get tough and they again jump ship, leaving the ruin to somebody who actually know what they are doing.

trump2016 10y ago

Great reply. Interesting how your decision to become a generalist stands in direct opposition to most of the replies to this thread: https://news.ycombinator.com/item?id=13409239 https://news.ycombinator.com/item?id=13409239 Given that you probably have much more experience than many of the people here, I'm going to assume that your advice is more sound than theirs.

pjc50 10y ago
The truth is somewhat in the middle, I think. An experienced generalist is a very different prospect to a graduate "generalist" - in some sense, all graduates are generalists because they don't have experience. See the thread the other day about how many people with physics degrees crosstrain into tech and programming. Generalism is insurance, while specialism can be more profitable if the speciality you pick ends up in demand.
- riprowan 10y ago
  I must add that I have undergraduate and graduate technical degrees and spent from 1983-2005 building lots and lots of apps (I started coding at ~ age 15). So I pursued "generalism" only after being a reasonably qualified (but not specialized) technologist.

jballanc 10y ago

> Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed. I'd like to simultaneously disagree and agree with you. If you were a 50 year old coder 10 years ago, then your only hope of remaining in the tech industry would be to add "Manager" to your job title. If you are a 50 year old coder today, that's still a sound direction to go, but increasingly becoming less necessary. If you'll be a 50 year old coder 10 years from now...I think you'll be ok. Yes, at 50 you almost certainly cannot crank out as much code as you can at 20, but so what? As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. The advantage you have at 50 over someone who is fresh and new at 20 is that you can recognize that there is very little that's happened in the last 30 years that is genuinely new. So, if you are 20, go ahead and spend your weekends on side projects learning the latest frameworks. As you continue to do this over the years and decades, shift to focusing more on patterns. By the time you reach 50, you might only generate half as much code as your younger colleagues, but you should be able to solve problems with a quarter of the code required, still making you twice as efficient as them. When coding was new, code was the only metric by which to measure coders, and non-technical management types would view anyone who generated less code as less valuable. If you're not writing 500 lines of code a day, the argument goes, then you should be managing coders who can. But management and problem solving are not a completely overlapping skill set. Some engineers make good managers, but most do not. Luckily, the more technically inclined individuals that populate the ranks of company management, the more this is being recognized and the more these companies are willing to hire the 50-year-old-coder-who-codes-less-but-solves-more-problems.

riprowan 10y ago
> As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. This is precisely my argument as a generalist. I may not write code as fast or even as elegantly as I once did, but I'm much, much better at "seeing around corners" to avoid problems, and I'm much more likely to "build the right thing" due to my very broad but not deep technical base. I do not fall into the trap of "when all you have is a hammer everything looks like a nail." > there is very little that's happened in the last 30 years that is genuinely new This is true, but try to convince your 20something peer group of it. They are all convinced that their technical skills are revolutionary. I studied waterfall systems engineering in 1998. But at the same time they also taught "RAD" iterative waterfall, or the precursor to Agile. I ran with RAD, and made it mine, so I've been doing something very similar to "Agile" for two decades. However, I still think that Gannt charts and top-down planning have value. Showing that shit to the wrong 20something developer is a great way to be excommunicated.

sporkenfang 10y ago

Er, one of the best developers I know is over 50. However, they consciously chose that path instead of tracking into management because they like being a principal engineer where that means they still get to work with code, but also have enough experience to anticipate pitfalls and make considered decisions.

mbrodersen 10y ago

I completely disagree with this. I am also a few years shy of 50 and way ahead compared with 20+ year old self-styled "ninja" developers. They simply don't know what they don't know. They truly believe that they are "experts" or "ninjas" because they have read a few tutorials on the latest soon-to-be-forgotten fashionable language/framework. Or believe that framework/language X is truly something new because a "hello world" web application is easy to write. And then a year later, when things get tough and the realise that the wonder framework/language has limitations, they jump ship to yet another shiny "silver bullet" framework/language that will save them from having to actually learn the hard stuff, allowing themselves to still believe that they are "ninjas". Meanwhile, people who actually know their stuff take over the ruins of their efforts and make it work. Rewriting it step by step to fix it.

mbrodersen 10y ago
And how do I know this by the way? Because I have done it many many times in my career. Taking over a ruin build by "ninjas" and making it actually work and bug free in production. Meanwhile the "ninjas" have jumped ship to another company, building a new ruin with some new "better" framework/language. Until of course things get tough and they again jump ship, leaving the ruin to somebody who actually know what they are doing.