3 ms·

This is exactly the tone I try to strike, especially with junior colleagues. I never want to make someone’s decision seem unambiguously wrong-headed when it com

This is exactly the tone I try to strike, especially with junior colleagues. I never want to make someone’s decision seem unambiguously wrong-headed when it comes to subjective engineering matters. That just breaks someone’s confidence.

Aeolun 7y ago
Even if their decisions are sometimes unambiguously wrong-headed. It’s just an experience thing, but I’m trying to figure out how to tell them ‘trust me, I’ve made this mistake before, please don’t do it’, without trying to explain the 2 or 3 years of experience that prompt it.
- stevens32 7y ago
  Explaining the experience would make it a learning moment, "trust me don't do this" doesn't do much to legitimately motivate an alternative choice
- asdfasgasdgasdg 7y ago
  Hopefully you are able to summarize -- that's what I try to do. Just asking for people to blindly trust you is a big ask, for two reasons. First, experienced people often develop mistaken beliefs. They try something and it happens to work, even though it might even be wrong in principle. Without any rationale, how is the person you're talking to going to judge whether the beliefs you've developed are correct? Second, even if they're willing to trust you, just getting the rule handed down does not grow them as an engineer. I might prefer to make a mistake and learn than take the right path without understanding the reasons. In fact, I have done so, intentionally. So, again, IMO, the goal you've mentioned in this comment ("figure out how to tell them `trust me...`") is an incorrect goal, and one you should not pursue.
- gregmac 7y ago
  It's a good opportunity to teach them. You could ask questions that lead them to the same conclusion (with the benefit of hindsight from your experience): "What happens if this system is terminated before the final write call completes?" "How does this handle someone accidentally starting another instance of the application at the same time?" "If this external service we use is down, what happens?" You could also walk through the story of your prior mistake, draw parallels to the new code, and then discuss how to avoid it.

Aeolun 7y ago

Even if their decisions are sometimes unambiguously wrong-headed. It’s just an experience thing, but I’m trying to figure out how to tell them ‘trust me, I’ve made this mistake before, please don’t do it’, without trying to explain the 2 or 3 years of experience that prompt it.

stevens32 7y ago
Explaining the experience would make it a learning moment, "trust me don't do this" doesn't do much to legitimately motivate an alternative choice
asdfasgasdgasdg 7y ago
Hopefully you are able to summarize -- that's what I try to do. Just asking for people to blindly trust you is a big ask, for two reasons. First, experienced people often develop mistaken beliefs. They try something and it happens to work, even though it might even be wrong in principle. Without any rationale, how is the person you're talking to going to judge whether the beliefs you've developed are correct? Second, even if they're willing to trust you, just getting the rule handed down does not grow them as an engineer. I might prefer to make a mistake and learn than take the right path without understanding the reasons. In fact, I have done so, intentionally. So, again, IMO, the goal you've mentioned in this comment ("figure out how to tell them `trust me...`") is an incorrect goal, and one you should not pursue.
gregmac 7y ago
It's a good opportunity to teach them. You could ask questions that lead them to the same conclusion (with the benefit of hindsight from your experience): "What happens if this system is terminated before the final write call completes?" "How does this handle someone accidentally starting another instance of the application at the same time?" "If this external service we use is down, what happens?" You could also walk through the story of your prior mistake, draw parallels to the new code, and then discuss how to avoid it.