Hacker News new | ask | show | jobs
by bmj 3271 days ago
I work in an organization that is relatively balanced as far as age goes (I'm 45). The most senior-level engineers tend to be older than me, though there are a few younger guys (still over 30). Perhaps I'm just fortunate, but here's what I've observed:

We tend to be fairly agile with regard to new technologies, and much of that is driven by the architects. A few of the young folks will recommend bleeding edge platforms/libraries/techniques. Some of this stuff has been accepted, some of it hasn't. It is almost always filtered through the lens of experience ("what happened when we tried to introduce x? ").

Experience counts, primarily because one group has been burned in the past by accepting recommendations from just-out-of-college engineers. That's not to say the younger devs don't know anything, but they have precious little experience shipping actual product.

(We work in the medical domain, so "move fast and break things" doesn't work so well in a highly-regulated industry).

On the other hand, our senior build engineer is more, uh, established in his ways, and we are currently stuck on an antiquated version control system. This particular engineer also wields quite a bit of influence to the larger company, so his way tends to be the way we go (unfortunately).

At the end of the day, I think you find stuck-in-their-old-way folks in an industry. This is not at all unique to software engineering.

1 comments

In some cases, the Old Ways and the Old Software is better, and it takes wisdom and experience to identify these cases. "Because it's old" is almost never a good reason not to use some software or technique (code does not rot). "Because it's new" is sometimes a good reason to try something, though.