4 ms·

The best developers only have 10 years experience. 10 years is enough to understand software, process, and the rest at a deep level. You may have expertise in

by _ah 6y ago

The best developers only have 10 years experience. 10 years is enough to understand software, process, and the rest at a deep level. You may have expertise in a particular area. You know pretty much all the things that are available to know. After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 10 years matters. One career mode is to shift to management. Or move to a technical leadership role where durable interpersonal relationships matter. The other career mode is to keep learning. Learn the new stack, the new language, the new whatever. Keep learning. I think that some developers hit trouble around 40 because they spent their first 10 years learning, then realized that they knew everything and coasted for 5-7 more, and then show up at 40 years old completely out of touch. Imagine a hiring manager considering someone with only 2 years of relevant experience (and a demonstrated unwillingness to learn), who is nevertheless convinced that he is super-senior and demanding compensation to match. That's the reality. I think that much of what we call ageism is just the natural consequences of a fixed mindset. Make every 10 years shine. "What have you done for me lately?"

downerending 6y ago
> After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 10 years matters. The experience you're really paying for with an older developer goes way beyond that. It's having a "deep" memory of a number of projects that have failed. It's having a true understanding of the value of quality and reliability. And being able to set the right level for each situation. It's about taking the time to get the requirements right, rather than just implementing what it sounds like the customer wants, only to find out months in that they don't even know. It's about showing up to the job every day. It's about knowing better than to just jump to the next job after a few months. If you want to experience youth, ask a young team how they're planning to deal with disasters, and watch the blank looks. Even for the tech aspects, it's very useful to have experienced the history to know why things are the way they are now. One of the reasons I'm so valuable now is because of what I was doing 25 years ago. As you're implicitly noting, it's hard to sell that, but that doesn't mean it's not so.
- _ah 6y ago
  I agree, there is a lot of context that comes with experience. However two things remain true: 1. Experience without knowing the latest stack is useless for a pure developer role. 2. Leaning into the deep memory of past failures is more consistent with a technical lead, which is one of the "other" growth paths.
  - downerending 6y ago
    You can learn a "stack" in a month or three. Hard to acquire experience at a rate higher than one day per day.
slg 6y ago
Java - first released 24 years ago. C - first released 48 years ago. Python - first released 30 years ago. C++ - first released 35 years ago. C# - first released 20 years ago. VB - first released 29 years ago. Javascript - first released 24 years ago. PHP - first released 25 years ago. SQL - first released 46 years ago. R - first released 26 years ago. Those are currently the top 10 most popular languages according the TIOBE Index. The idea that everything turns over immediately is maybe true in the valley, but it isn't close to being true industrywide.
- _ah 6y ago
  This is true, but for a pure dev role (writing code, closing tickets, no technical leadership) I maintain that a C expert with 10 (recent) years' experience is functionally indistinguishable for a C expert with 35 years.
  - slg 6y ago
    Is that because the previous 25 years experience from the one dev is now obsolete or because you essentially know all it is you need to know to be a great dev after 10 years? The first comment stated the former, but this one seems to be implying that latter.
microtherion 6y ago
I agree with your gist of "keep learning", but some of what you say about obsolescence of knowledge seems overstated to me. > The languages you learned? Gone. I'm not sure if I'll ever get to write Modula-2 again. But every few years, knowing some PostScript can come in handy. FORTH has a tendency to pop up on every resource constrained platform for a while. Tcl has preserved some niches. And C++ is both old and new technology. Some details have stuck around for 35 years, but if you don't reinvent your style every 10 years or so, you risk becoming obsolete. > The APIs and weird hardware limitations? Irrelevant. Hardware limitations tend to come in cycles. Just when resource constraints on macOS seemed irrelevant, along came iOS with its murderous daemons baying for the blood of resource hungry processes. Just when resource constraints in iOS seemed irrelevant, along came watches. And a Commodore PET with its 7167 bytes of available RAM and fairly accessible hardware ports has some similarity with an Arduino Uno. So while I think it's unwise to bank on some knowledge never ceasing to be useful, or that no new technology is ever worth learning, knowing old stuff in itself is not a drawback.

by _ah 6y ago

downerending 6y ago

> After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 10 years matters. The experience you're really paying for with an older developer goes way beyond that. It's having a "deep" memory of a number of projects that have failed. It's having a true understanding of the value of quality and reliability. And being able to set the right level for each situation. It's about taking the time to get the requirements right, rather than just implementing what it sounds like the customer wants, only to find out months in that they don't even know. It's about showing up to the job every day. It's about knowing better than to just jump to the next job after a few months. If you want to experience youth, ask a young team how they're planning to deal with disasters, and watch the blank looks. Even for the tech aspects, it's very useful to have experienced the history to know why things are the way they are now. One of the reasons I'm so valuable now is because of what I was doing 25 years ago. As you're implicitly noting, it's hard to sell that, but that doesn't mean it's not so.

_ah 6y ago
I agree, there is a lot of context that comes with experience. However two things remain true: 1. Experience without knowing the latest stack is useless for a pure developer role. 2. Leaning into the deep memory of past failures is more consistent with a technical lead, which is one of the "other" growth paths.
- downerending 6y ago
  You can learn a "stack" in a month or three. Hard to acquire experience at a rate higher than one day per day.

slg 6y ago

Java - first released 24 years ago. C - first released 48 years ago. Python - first released 30 years ago. C++ - first released 35 years ago. C# - first released 20 years ago. VB - first released 29 years ago. Javascript - first released 24 years ago. PHP - first released 25 years ago. SQL - first released 46 years ago. R - first released 26 years ago. Those are currently the top 10 most popular languages according the TIOBE Index. The idea that everything turns over immediately is maybe true in the valley, but it isn't close to being true industrywide.

_ah 6y ago
This is true, but for a pure dev role (writing code, closing tickets, no technical leadership) I maintain that a C expert with 10 (recent) years' experience is functionally indistinguishable for a C expert with 35 years.
- slg 6y ago
  Is that because the previous 25 years experience from the one dev is now obsolete or because you essentially know all it is you need to know to be a great dev after 10 years? The first comment stated the former, but this one seems to be implying that latter.

microtherion 6y ago

I agree with your gist of "keep learning", but some of what you say about obsolescence of knowledge seems overstated to me. > The languages you learned? Gone. I'm not sure if I'll ever get to write Modula-2 again. But every few years, knowing some PostScript can come in handy. FORTH has a tendency to pop up on every resource constrained platform for a while. Tcl has preserved some niches. And C++ is both old and new technology. Some details have stuck around for 35 years, but if you don't reinvent your style every 10 years or so, you risk becoming obsolete. > The APIs and weird hardware limitations? Irrelevant. Hardware limitations tend to come in cycles. Just when resource constraints on macOS seemed irrelevant, along came iOS with its murderous daemons baying for the blood of resource hungry processes. Just when resource constraints in iOS seemed irrelevant, along came watches. And a Commodore PET with its 7167 bytes of available RAM and fairly accessible hardware ports has some similarity with an Arduino Uno. So while I think it's unwise to bank on some knowledge never ceasing to be useful, or that no new technology is ever worth learning, knowing old stuff in itself is not a drawback.