Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The futility of “I told you so” in software engineering teams

humza.sh

Post reply on HN
Print view View original

51–60 of 84 posts

Re: The futility of “I told you so” in software engineering teams

#51

Post by throwaway987978 »

g051051 wrote: post #27
yomly wrote: post #24

At Amazon you had "disagree and commit" and (used to have) "vocally self critical". The commit part is actually very important - once the TEAM makes a DECISION everyone is on board with it and runs with it. You don't half ass it or sabotage it. But if it does go wrong, the decision maker should have the strength of character to acknowledge "you were right" These two factors held in tension and taken at face value (ra…

It's difficult to "commit" to something that is clearly and utterly wrong.

But what if you're the one who's wrong?

Re: The futility of “I told you so” in software engineering teams

#52

Post by flukus »

aeternum wrote: post #44
flukus wrote: post #35

Earlier quoted context omitted.

> The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. It's also extremely dismissive of experience. Sometimes you just know an idea won't work out because you've been down that road before. You can't just distill 20 years of experience into strong counter arguments for every proposal, it's just too time consuming, espe…

How do you handle input that does need to be dismissed? I've seen entire teams stall out and become stuck in perpetual design loops due to 1-2 members constructing endless 'what-if' scenarios. Engineering involves tradeoffs, there is rarely a single perfect solution. There are also times like when attempting to find product-market fit when pointing out all the possible problems is close to useless. There are so many…

> How do you handle input that does need to be dismissed?

Hierarchy. You need someone to make the calls and the team to follow them, even if it's going to be wrong. That should be enough to break any perpetual design loop and move forward. Ultimately this hierarchy will exist anyway, the person paying you gets to decide what you're going to do or delegate that decision to someone else. Soliciting feedback along they way is important, but ultimately you need some decision makers.

> There are also times like when attempting to find product-market fit when pointing out all the possible problems is close to useless

This is building solution and then finding the problem which can be entirely avoided.

Re: The futility of “I told you so” in software engineering teams

#53

Post by flukus »

XorNot wrote: post #36
deathanatos wrote: post #17

> Your “I told you so” only highlights that you need to construct stronger arguments. Most of the time I'm not been listened to and should have been, I feel like it is out of apathy or laziness, not out of whether the argument was sufficiently strong. My request "this will not work for X reasons" is almost always followed by "and Y is what we need to do", but Y implies … additional work. The culture of current corpor…

The real trick is that caring about anything in the modern corporate workplace is a mistake. Unless you hold equity and board position in the company, then you are completely replaceable at any time for any reason. The only thing you should be doing is ensuring that the chain of decision making is documented so blame flows upwards. And exercise some discretion in ensuring you get away from managers with a track histo…

> The real trick is that caring about anything in the modern corporate workplace is a mistake

If I could go back 20 years and give myself one piece of mental health advice, this would be it.

Re: The futility of “I told you so” in software engineering teams

#55

Post by pdimitar »

> “How will I make my case differently next time?”

By leaving the company, 90% of the time. If you are repeatedly ignored and then also ridiculed for pointing out that you saw the failure coming then that team's leader is very likely beyond reason.

Life is not that long. Move on to greener pastures.

Re: The futility of “I told you so” in software engineering teams

#56

Post by bfuclusion »

setpatchaddress wrote: post #9
barrkel wrote: post #4

If you feel like you're saying "I told you so" often, you should leave. Either you're not in a position to have your opinions count, or you've given up fighting for them and are burning out. (A third option is that you're deluded, and are forgetting about all the times where what you told people didn't come out true. Watch for that, and be more humble.)

Fourth option from TFA: > Your “I told you so” only highlights that you need to construct stronger arguments. All of these may be true. They're not necessarily a reason to leave.

Yes, and no. In the best case you improve your communication skills and become a more valuable employee, in which case you should consider leaving to get more comp. If you don't make improvements, then you're not really able to be effective, and you should consider leaving because there might be a better fit elsewhere.

Re: The futility of “I told you so” in software engineering teams

#57

Post by contingencies »

In an engineering context, people should convince others with evidence. A test case showing an objective improvement would be ideal. Pontification about the relative merits of disparate approaches is irrelevant. This can be avoided by having an benevolent dictator / architect make those decisions. While step one is getting the job done (executing even a bad plan is superior to no working product), I have noticed that sometimes the most efficient way to get the job done is to defer it until later, when the problem space is better understood. Tradeoffs are the great beauty of engineering and perhaps why the field successfully holds the attention of so many minds.

Re: The futility of “I told you so” in software engineering teams

#58

Post by threatofrain »

flukus wrote: post #35
TheCowboy wrote: post #10

The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. If their reasoning was presented initially and matches up with what was the cause of the problems, then yes, they did tell you so and you should probably take note. Otherwise you're letting yourself or other managers off the hook every time. The culture should support…

> The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. It's also extremely dismissive of experience. Sometimes you just know an idea won't work out because you've been down that road before. You can't just distill 20 years of experience into strong counter arguments for every proposal, it's just too time consuming, espe…

What matters here is credibility of which experience is only one contributor. Everything you say is mitigated or boosted by credibility.

If a person has experience but finds that their credibility isn’t what they want it to be, maybe something else is up.

Re: The futility of “I told you so” in software engineering teams

#59

Post by yomly »

g051051 wrote: post #27
yomly wrote: post #24

At Amazon you had "disagree and commit" and (used to have) "vocally self critical". The commit part is actually very important - once the TEAM makes a DECISION everyone is on board with it and runs with it. You don't half ass it or sabotage it. But if it does go wrong, the decision maker should have the strength of character to acknowledge "you were right" These two factors held in tension and taken at face value (ra…

It's difficult to "commit" to something that is clearly and utterly wrong.

If it is clearly and utterly wrong, why is it so hard for you to convince your team/business? /troll

Being charitable, sometimes the team/org needs to obtain the group learning. If you've had your say, then time will prove you right and people will remember.

If the team/org won't remember AND they just like to rain down decisions on you from above, why you working there...?

In any case communication is HARD. It's always easy to blame people for not listening, but you can't control other people, only yourself. So the most constructive thing to focus on is doing everything in your power to make it clearly and utterly obvious what you can see that no one else can see. That will stay with you and eventually teams will listen to you.

Post reply on HN