3 ms·

The thing is ... The industry needs us. It's making a mess all over and valorizing complexity and novelty. Constantly. Programmers with experience in our age ra

The thing is ... The industry needs us. It's making a mess all over and valorizing complexity and novelty. Constantly. Programmers with experience in our age range have, I think, a better sense of how to manage this and encourage simplicity (partially out of necessity). But age and novelty bias in our industry means this knowledge doesn't pass on. It's tough to tell younger engineers that have cut their teeth swimming in intricacies and edge cases and integration nightmares and constantly surfing on the edge of chaos, and managing it, that they're likely contributing to the problem, not fixing it. But someone needs to. I can't remember details like I used to, things mark&sweep out of my brain much faster they used to. (Probably not just because I'm older but because as a parent, home owner, and spouse... I just have a lot to manage on top of it.) But.. really... a good system, a well-built system ... should be resilient to that, and people with experience.. that's hopefully what we build.

alemanek 2y ago
I have been lucky enough to have been the youngest person on every team until my mid 30s. I worked with some truly gifted engineers, who had almost no ego, over the course of my career they just were much older than me. When I reflect I do cringe a bit at what I was zealous about and things I took way too far. But, I do think the discussion, sometimes debate, around the fancy/new vs tried/true resulted in much better results. Now that I am old, but not that old, the younger engineers who are passionately discovering new tools and “new” design patterns keep me interested in software development. Being able to share where things come from then we can compare/contrast together. It is rarely a straight copy and it’s fun to see how things get better/worse with reinvention. So, I think trying to get a mix of ages on a team is really beneficial. Passionate young engineers help prevent the old engineers from getting too jaded.
- cmrdporcupine 2y ago
  I too was always the youngest person on every team... until I wasn't, and it seemed like I went from youngest to oldest in a blink and I still can't figure out how that can happen. I got into the industry during the .com boom with no degree, without finishing university, so kind of jumped the queue, age-wise, I guess. And yes, I often cringe in remembrance of past-self. I cringe at present self, too, though :-)
away271828 2y ago
On the other hand, you have to guard against being that person who is in a perpetual state of "Benn there, done that. Didn't work the last 5 times we tried it." Because sometimes the circumstances/market/tech ecosystem genuinely are different.
- bruce511 2y ago
  The key us in understanding why the previous times failed. What constraints existed then, which possibly no longer exist now. Projects fail for many reasons. Technical, market, capital, time and so on. But things change. Building an add-on for electric cars would likely fail 20 years ago, again 10 years ago. But now? Or 10 years from now? Only by -really- understanding what caused a project to fail can you determine if that barrier is no longer in place. Which means you can try again, and potentially find the next barrier or success.
cratermoon 2y ago
I'm in the retirement age bracket. My last experience as a consultant led to disgust with valorizing quantity of work as measured by an arbitrary metric susceptible to simple gaming. That, and prioritizing "new" features over maintenance because the former were booked as CapEx work, thus amortizable, while maintenance was booked as OpEx, combined with companies wanting to minimize CapEx ratio for accounting purposes. Notice how little of what is measured and managed has anything to do with building working software to satisfy user needs?

alemanek 2y ago

I have been lucky enough to have been the youngest person on every team until my mid 30s. I worked with some truly gifted engineers, who had almost no ego, over the course of my career they just were much older than me. When I reflect I do cringe a bit at what I was zealous about and things I took way too far. But, I do think the discussion, sometimes debate, around the fancy/new vs tried/true resulted in much better results. Now that I am old, but not that old, the younger engineers who are passionately discovering new tools and “new” design patterns keep me interested in software development. Being able to share where things come from then we can compare/contrast together. It is rarely a straight copy and it’s fun to see how things get better/worse with reinvention. So, I think trying to get a mix of ages on a team is really beneficial. Passionate young engineers help prevent the old engineers from getting too jaded.

cmrdporcupine 2y ago
I too was always the youngest person on every team... until I wasn't, and it seemed like I went from youngest to oldest in a blink and I still can't figure out how that can happen. I got into the industry during the .com boom with no degree, without finishing university, so kind of jumped the queue, age-wise, I guess. And yes, I often cringe in remembrance of past-self. I cringe at present self, too, though :-)

away271828 2y ago

On the other hand, you have to guard against being that person who is in a perpetual state of "Benn there, done that. Didn't work the last 5 times we tried it." Because sometimes the circumstances/market/tech ecosystem genuinely are different.

bruce511 2y ago
The key us in understanding why the previous times failed. What constraints existed then, which possibly no longer exist now. Projects fail for many reasons. Technical, market, capital, time and so on. But things change. Building an add-on for electric cars would likely fail 20 years ago, again 10 years ago. But now? Or 10 years from now? Only by -really- understanding what caused a project to fail can you determine if that barrier is no longer in place. Which means you can try again, and potentially find the next barrier or success.

cratermoon 2y ago

I'm in the retirement age bracket. My last experience as a consultant led to disgust with valorizing quantity of work as measured by an arbitrary metric susceptible to simple gaming. That, and prioritizing "new" features over maintenance because the former were booked as CapEx work, thus amortizable, while maintenance was booked as OpEx, combined with companies wanting to minimize CapEx ratio for accounting purposes. Notice how little of what is measured and managed has anything to do with building working software to satisfy user needs?