Live data from Hacker News

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

humza.sh

41–50 of 84 posts

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

#41

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…

In my experience a well reasoned and methodical "that won't work" is far less common than plain old grumbling.

The cliche of the curmudgeon developer exists for a reason. There are a lot of people who default to picking holes in any plan. They don't acknowledge the times they were wrong (and the project succeeded) or the fact that complaining about a solution doesn't actually help the problem get solved.

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

#42

> 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 version of this that continually bites me is when someone is designing what is essentially a distributed system but doesn't know that's what they are designing. System W -> System X -> System Y -> System Z are connected with the assumption no guarantees or coherency checks are needed. Might as well just email spreadsheets...

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

#43
post #27

Earlier quoted context omitted.

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

The faster it fails, the faster you might have an opportunity to point out the failure points and suggest the correct solution.

Sometimes the solution is 'not to do that bad thing' and quite often there's no going back from that.

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

#44
post #35

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…

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 unknowns that the most important thing is often to get your product out there and start validating your assumptions and collecting data.

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

#45
That article reads as a piece justifying the bullies.

1) We’re going to make a thing, but you disagree about how we should do it, so you must be not a team player, shut up, you’re ruining the spirit.

2) We’re incompetent doofuses and we’ve broken the thing as you have predicted, but you’re still guilty because you weren’t persuasive enough.

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

#46
Things are not so black and white in most non-trivial projects. The team could conclude that there is an 80% chance of success, while you may think there's only a 40% chance of success. If the project fails, does that mean you were right? It's entirely possible that the correct estimate was indeed 80%, but the universe rolled the dice into the 20% zone. Saying "I told you so" may not be the most constructive response.

On the other hand, if you are consistently right 9 times out of 10, and the team isn't listening to you, then, yeah, maybe it's time to find another team. But be careful of selective memory: it could be that you are always predicting failure, but you only remember the times when the project failed, not the times when the project succeeded and you were wrong.

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

#47
Your “I told you so” only highlights that you need to construct stronger arguments.

No, sorry. Most places don't allow people time to construct stronger arguments. Most experienced people have a gut feel for what is going to go wrong. We are pattern machines, and they are feeling the pattern. That would be part of the definition for experience. Decent decision makers have worked on the skills to ask questions when experienced people have those gut feelings and figure out the arguments that lead to the feeling.

Further, that sentence just ticks me off. You were warned. You didn't like the warning, and got bit. Don't blame the person telling you it was going to be a problem. Blame yourself for not having the skill or desire to understand the warning, work out what the experience was telling the person, and gaining some knowledge. Failure is a great teacher, but internalizing the experience of others is way cheaper.

I remember when CRC cards were so useful for the role-play to walk different scenarios through the system. It would bring out the experience and show where things might go off the rails. It was like a read-through of a new play.

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

#48
Sometimes you can't even say "I told you so" because people refuse to understand that there is a problem.

Like, when services randomly fail to start up, and instead of fixing the bad config, people write docs saying you should try the command multiple times ... what are you gonna do?

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

#49

Earlier quoted context omitted.

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.

One can often take these to your manager or your team retrospective, and ask questions, turning it around to be forward-looking: "During planning, I expressed my concerns that [bad thing that happen] might happen. Is there something I do to raise this matter more effectively in the future? Do we need to improve communications more generally?"

That is often a futile exercise on team dynamic platitudes. What do you imagine would be a good / actionable answer for that question?

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

#50

Ursula K. LeGuin had an essay in her collection Languages of the Night (can't remember exactly which essay) where she said “Nobody who says, ‘I told you so’ has ever been, or will ever be, a hero.”

> Ursula K. LeGuin had an essay in her collection Languages of the Night (can't remember exactly which essay) where she said “Nobody who says, ‘I told you so’ has ever been, or will ever be, a hero.”

Maybe that's because they weren't in the position to make the choice and change the outcome. You can't be a hero on the battlefield if you never leave the barracks.

Post reply on HN