The conversation

Lessons learnedExperience excerpt · English

Chances based on my experience? 50:50 Old engineers will say things that are hard learned lessons …

Chances based on my experience? 50:50 Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't updated my judgement since, despite the world having changed a lot". The problem is that unless you really know things inside out or know the hard held opinions of your older collegue well, it can be hard to tell the two apart. In that case it only helps to talk about it in more detail and try to get to the root of where the judgement comes from. Then it could come to light that the warning to use PHP comes from a bad experience with PHP version <1.0 or that there is a number of bad experienced that are really useful for deciding the direction of a project. In the end many decisions are about taste. And nothing is as good as a way to keep arguing than matters of taste. …

Original discussionHow to Lead in a Room Full of Experts137 source comments · at import
2

What was this responding to?

Parent context · original excerpt

YZ

What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good. That's not to say that consensus always works. But it does mean the group needs to understand the objections and make decisions the team can live with. The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes. Sometimes there is time pressure or difficult people but the base assumption should be that people actually want to make the right decision, being difficult generally makes your life harder. Who would be responsible for executing on the decision and who would be responsible for the outcome? What are the consequences of strong arming the team into solutions they don't agree with?

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 2

Direct replies available in this import. Original-language excerpts.

BR

I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today. For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently. Like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field. All those habits proved to be bad in the long run. And today memory (and disk space) are abundant. But these old habits are hard to break. And that's before we talk about "modern" techniques, like version control etc. Experience is great. I'm a fan. But all too often experience is also "there was a bug I windows 95, so that API call is unreliable ".

Full original
LI

>Weigh all the pros/cons and make a choice. This is sound advice when people agree on which column things belong to :)

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.