[privateSFacct]

For front-end dev - some older developers are really tired of the constant churn. This can be a good thing if you can / already are off the endless new frontend bandwagon. But since a lot of junior folks are into the "latest and greatest" it can be very hard internally (and cement a perhaps resistance to change stereotype).

I'm a bit tired of folks saying older devs are not resistant to change. Reality - with experience some stuff just seems faddy at times over the course of longer career arcs. So yes, older devs can be bit resistant to jumping onto the latest bandwagon.

[hajile]

If someone learned lisp (or ML) in the 80s, very little from the “cutting edge” of languages would seem new at all. Likewise, most current framework trends have been around for decades.

I think the Junior mistake is searching for a programming panacea. While lots of bad designs exist, perfect designs do not.

[whoknowswhat11]

Exactly this - people spend more time talking about frameworks than solving problems sometimes - the framework will not solve it and people have built huge / successful apps w rudimentary stack

[convolvatron]

learned lisp and ML in the 80s. agree completely.

[abnry]

Do you think the fads will come and go with lower frequency as more time passes? Software engineering is a young field. I don't hear a lot about, for instance, fads in aerospace engineering but that could be because I hear little about it in general. Perhaps software engineering is always going to be "faddy" because of how flexible and reconfigurable software is in general.

[hajile]

I think it’s the latter. Aerospace engineers do have fads like the aerospike rocket engine. Nobody’s launched one (that I know of) because it simply doesn’t work yet. The cost of failure is just too catastrophic. Instead, there’s a focus on the tradeoffs and lots of experimentation to get it right.

In software, if the prototype didn’t work, you tweak it and try again or even deploy with known issues and fix in prod later (looking at you game companies). If you had to throw away all your code and start over completely with each iteration like you do with rockets, you’d see more discussion and testing out earlier (in fact, you tend to see this more in critical software —- eg, the software that controls those rockets).

Finally, very few companies throw as much money behind business software as they do at rockets. I’d bet heavily that v8, .net, hotspot, or even gcc (metaphorical engines for your code) have only a fraction of the resources spent on a new rocket design.

[throwawayboise]

> The cost of failure is just too catastrophic

Yes. Real engineers are responsible for life and death decisions in their designs. Software developers for the most part are not, and where they are, you don't see fads you see them using very long-proven and careful approaches.

[whoknowswhat11]

One thing - software engineering is harder to measure than hardware. Have a new wing design ? Amazing strength at low weight - you can actually test your design and measure if it’s better.

Software engineering is much muddier

[resoluteteeth]

That seems like something that would already be reflected on people's resumes, so it seems odd that a different photo would make a difference if that's the concern.