8 ms·

I see a lot of lack of appreciation for older, more experienced programmers in the field. Perhaps this is why things keep getting reinvented all the time, and t

I see a lot of lack of appreciation for older, more experienced programmers in the field. Perhaps this is why things keep getting reinvented all the time, and the pendulum keeps swinging back and forth as we don't learn from previous generation's experiences? Too much fad and hype driven development these days.

postalrat 4y ago
In this field everyone thinks they can do it better. Being humbled just means you are washed up.
- ryall 4y ago
  This is why you need older programmers, protection from the hubris of youth
trombone5000 4y ago
What's wrong with fad and hype driven development? It may be better to replace software regularly than to find yourself or your organization dependent on something ossified in place. In the long run it might be better to treat software as "fast fashion" rather than something meant to last forever.
- pjmlp 4y ago
  https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/ That is what is wrong.
  - trombone5000 4y ago
    From the link: > Pete concentrated on building a system [in COBOL] that works for him and his clients. If that system isn't replaced before Pete retires, it turns into a significant hidden risk. You don't know how dependent on something you are until you try to replace it with something else. If hype is driving the replacement, so be it. An organization can make replacement a regular practice and get good at it; or it can find out when it unexpectedly becomes necessary.
    - pjmlp 4y ago
      Pete could have discovered that even COBOL follows hype, no need to switch stacks. https://www.microfocus.com/en-us/products/visual-cobol/features https://www.microfocus.com/en-us/products/visual-cobol/featu...
- AnimalMuppet 4y ago
  > What's wrong with fad and hype driven development? The "flavor of the month" band wasn't as good as The Rolling Stones. That's not the end of the world if all you did was buy their CD, and then never listen to it again after the month was up. If you completely rebuilt your stereo to try to make that CD sound better, though, that gets more expensive. (Especially if you rebuild it again next month for a different band.) Development is more like rebuilding the stereo than buying the CD. It's expensive. It takes time and money that could be spent on other things. Worse, in replacing dependencies, you may replace a dependency on something that works with a dependency that doesn't work nearly as well. You may replace your Corvette with a Corvair. (And spend time and money to do it.) If you have battle-proven tech, there is a place for eventually replacing it. Eventually, though. Not very quickly. And when you do replace it, don't replace it with the fad of the month (or even the fad of the year).
- onion2k 4y ago
  What's wrong with fad and hype driven development? Ostensibly nothing, so long as you can tell when things are better. If you're trying new things and taking on new, better ideas quickly then you'll improve rapidly. If you're also "failing fast" and throwing out new things when they don't work then you'll improve even more rapidly. If you're abandoning good tech simply because it's old, and not fully understanding the drawbacks of the new things you're switching too, then you're building an empire of tech debt that all your good team members will eventually get sick of fire fighting and they'll leave. Novelty doesn't make people loyal. Working on strong tech that people are proud of does. Sometimes that requires a deep dive into some tech over a number of years.
cogman10 4y ago
What I find is you have people that gain 10 years of experience in 10 years and people that get 1 year of experience repeated 10 times. The field changes, it's changed significantly since I started 10 years ago. Yet there's a fairly large contingent of devs that aren't keeping up. I've interviewed old devs that are at the top of their game and old devs that are no better than the interns we have. I've worked with the same.
- postalrat 4y ago
  What are you basing your judgements on?
  - tester756 4y ago
    In my opinion: They lack foundational software engineering knowledge/opinions Use their IDEs as if they saw it for the first time Lack of experience when it comes to architecture
    - btschaegg 4y ago
      It becomes even worse if you run into people who operate on cutting edge knowledge from decades ago and insist on it. I've seen people organize their data in a cache-pessimal way in order to squeeze out a couple of CPU cycles, for example. It becomes really tiring when you constantly have to whip up a benchmark just to settle debates on things that have been common knowledge for basically forever now.
      - tester756 4y ago
        Haha, I've experienced that. You can argue everything with "because of performance reasons" because it requires way more effort to actually check it.
      - neonsunset 4y ago
        Or sometimes it's the opposite and you get shoved "Premature optimization..." quote up your change request during every code review and fighting person's bad habits requires you writing benchmark or referencing 5 articles with examples for every little thing. It's maddening.
TAForObvReasons 4y ago
"Job security" Without being too reductive, software is subject to the theory of economic profit and thus tends to ~free. Churn is the natural response. It artificially create the sort of work that forces users to spend money in the future.
beebmam 4y ago
> Perhaps this is why things keep getting reinvented all the time This is a good thing, in my opinion. Not only does reinventing something give a new generation an opportunity to learn how to design, but it also gives that new generation context and knowledge about the product when it is complete. > we don't learn from previous generation's experience This is a serious cultural failure (and it happens globally). Very few of us sincerely engage with the past, in my opinion, because it takes a lot of effort to do so. And either it's not worth the effort on an individual level, or we haven't been allocated the time/resources by management that it would take to sincerely engage with the past.
- deleted 4y ago
  [deleted]
bmitc 4y ago
One thing I have been curious about is: where are all the old programmers? I want to learn from them but very few put out material, and so you gotta get lucky that you work with one. Most of the material out there on YouTube, books, and blogs seems mostly dominated by younger people (30s and below). I'd love to see people who really know what they're doing put out some material.
- CrLf 4y ago
  Perhaps they get used to nobody listening and just stop talking.
- wink 4y ago
  Losing the enthusiasm to blog and create videos. Also I guess a certain lack of not giving a damn if you actually produce something valuable. For example 10-15 years ago I was very eager to write down every little thing I learned, but after a certain time you either notice that you don't know a lot, in the grand scheme of things, and your bar for "will I publish this" can go up a lot, or you're suddenly working on highly specialized or super secret (offficialy) tech where you can't really publish anything... or you actually notice that you become proficient in stuff you find generally uninteresting. Best example is.. enjoying your work but not feeling in the mood to spend your free time on explaining some weird quirks to the general public. Also writing books is something you need to enjoy or at least feel driven to do. For most people it's not worth it in a monetary sense either.
bsder 4y ago
Part of it is: "What are you programming?" Phone development is a continuous slog through ever-changing APIs. An older programmer hardly helps here. In fact, this is probably one of the few places where I might agree that younger programmers are better--it takes an enormous amount of energy to keep up with phone programming changes and that's something that youngsters have aplenty. Web programming is a similar treadmill except for the fact that you can opt-out. If the client demands some fad technology, well, then experience doesn't matter. If the client simply wants a solution, then experience can be a godsend. I've watched a couple experienced programmers deliver amazing web solutions really fast--they used well-trod, boring technology that they knew very well. Embedded programming simply demands greybeards. I haven't seen an embedded project yet that succeeded if it didn't have a majority of people with 15+ years of experience and couple above 25+ years. So much will go wrong that it's more important to design around the failure modes up front--and you have to have been around the block a couple of time to understand what those are in order to avoid them.

postalrat 4y ago

In this field everyone thinks they can do it better. Being humbled just means you are washed up.

ryall 4y ago
This is why you need older programmers, protection from the hubris of youth

trombone5000 4y ago

What's wrong with fad and hype driven development? It may be better to replace software regularly than to find yourself or your organization dependent on something ossified in place. In the long run it might be better to treat software as "fast fashion" rather than something meant to last forever.

pjmlp 4y ago
https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/ That is what is wrong.
- trombone5000 4y ago
  From the link: > Pete concentrated on building a system [in COBOL] that works for him and his clients. If that system isn't replaced before Pete retires, it turns into a significant hidden risk. You don't know how dependent on something you are until you try to replace it with something else. If hype is driving the replacement, so be it. An organization can make replacement a regular practice and get good at it; or it can find out when it unexpectedly becomes necessary.
  - pjmlp 4y ago
    Pete could have discovered that even COBOL follows hype, no need to switch stacks. https://www.microfocus.com/en-us/products/visual-cobol/features https://www.microfocus.com/en-us/products/visual-cobol/featu...
AnimalMuppet 4y ago
> What's wrong with fad and hype driven development? The "flavor of the month" band wasn't as good as The Rolling Stones. That's not the end of the world if all you did was buy their CD, and then never listen to it again after the month was up. If you completely rebuilt your stereo to try to make that CD sound better, though, that gets more expensive. (Especially if you rebuild it again next month for a different band.) Development is more like rebuilding the stereo than buying the CD. It's expensive. It takes time and money that could be spent on other things. Worse, in replacing dependencies, you may replace a dependency on something that works with a dependency that doesn't work nearly as well. You may replace your Corvette with a Corvair. (And spend time and money to do it.) If you have battle-proven tech, there is a place for eventually replacing it. Eventually, though. Not very quickly. And when you do replace it, don't replace it with the fad of the month (or even the fad of the year).
onion2k 4y ago
What's wrong with fad and hype driven development? Ostensibly nothing, so long as you can tell when things are better. If you're trying new things and taking on new, better ideas quickly then you'll improve rapidly. If you're also "failing fast" and throwing out new things when they don't work then you'll improve even more rapidly. If you're abandoning good tech simply because it's old, and not fully understanding the drawbacks of the new things you're switching too, then you're building an empire of tech debt that all your good team members will eventually get sick of fire fighting and they'll leave. Novelty doesn't make people loyal. Working on strong tech that people are proud of does. Sometimes that requires a deep dive into some tech over a number of years.

cogman10 4y ago

What I find is you have people that gain 10 years of experience in 10 years and people that get 1 year of experience repeated 10 times. The field changes, it's changed significantly since I started 10 years ago. Yet there's a fairly large contingent of devs that aren't keeping up. I've interviewed old devs that are at the top of their game and old devs that are no better than the interns we have. I've worked with the same.

postalrat 4y ago
What are you basing your judgements on?
- tester756 4y ago
  In my opinion: They lack foundational software engineering knowledge/opinions Use their IDEs as if they saw it for the first time Lack of experience when it comes to architecture
  - btschaegg 4y ago
    It becomes even worse if you run into people who operate on cutting edge knowledge from decades ago and insist on it. I've seen people organize their data in a cache-pessimal way in order to squeeze out a couple of CPU cycles, for example. It becomes really tiring when you constantly have to whip up a benchmark just to settle debates on things that have been common knowledge for basically forever now.
    - tester756 4y ago
      Haha, I've experienced that. You can argue everything with "because of performance reasons" because it requires way more effort to actually check it.
    - neonsunset 4y ago
      Or sometimes it's the opposite and you get shoved "Premature optimization..." quote up your change request during every code review and fighting person's bad habits requires you writing benchmark or referencing 5 articles with examples for every little thing. It's maddening.

TAForObvReasons 4y ago

"Job security" Without being too reductive, software is subject to the theory of economic profit and thus tends to ~free. Churn is the natural response. It artificially create the sort of work that forces users to spend money in the future.

beebmam 4y ago

> Perhaps this is why things keep getting reinvented all the time This is a good thing, in my opinion. Not only does reinventing something give a new generation an opportunity to learn how to design, but it also gives that new generation context and knowledge about the product when it is complete. > we don't learn from previous generation's experience This is a serious cultural failure (and it happens globally). Very few of us sincerely engage with the past, in my opinion, because it takes a lot of effort to do so. And either it's not worth the effort on an individual level, or we haven't been allocated the time/resources by management that it would take to sincerely engage with the past.

deleted 4y ago
[deleted]

bmitc 4y ago

One thing I have been curious about is: where are all the old programmers? I want to learn from them but very few put out material, and so you gotta get lucky that you work with one. Most of the material out there on YouTube, books, and blogs seems mostly dominated by younger people (30s and below). I'd love to see people who really know what they're doing put out some material.

CrLf 4y ago
Perhaps they get used to nobody listening and just stop talking.
wink 4y ago
Losing the enthusiasm to blog and create videos. Also I guess a certain lack of not giving a damn if you actually produce something valuable. For example 10-15 years ago I was very eager to write down every little thing I learned, but after a certain time you either notice that you don't know a lot, in the grand scheme of things, and your bar for "will I publish this" can go up a lot, or you're suddenly working on highly specialized or super secret (offficialy) tech where you can't really publish anything... or you actually notice that you become proficient in stuff you find generally uninteresting. Best example is.. enjoying your work but not feeling in the mood to spend your free time on explaining some weird quirks to the general public. Also writing books is something you need to enjoy or at least feel driven to do. For most people it's not worth it in a monetary sense either.

bsder 4y ago

Part of it is: "What are you programming?" Phone development is a continuous slog through ever-changing APIs. An older programmer hardly helps here. In fact, this is probably one of the few places where I might agree that younger programmers are better--it takes an enormous amount of energy to keep up with phone programming changes and that's something that youngsters have aplenty. Web programming is a similar treadmill except for the fact that you can opt-out. If the client demands some fad technology, well, then experience doesn't matter. If the client simply wants a solution, then experience can be a godsend. I've watched a couple experienced programmers deliver amazing web solutions really fast--they used well-trod, boring technology that they knew very well. Embedded programming simply demands greybeards. I haven't seen an embedded project yet that succeeded if it didn't have a majority of people with 15+ years of experience and couple above 25+ years. So much will go wrong that it's more important to design around the failure modes up front--and you have to have been around the block a couple of time to understand what those are in order to avoid them.