Live data from Hacker News

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

humza.sh

11–20 of 84 posts

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

#11
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.

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

Often you raise an issue, which is ignored or underprioritized. Later, priorities may shift from upper management, to make it an actionable argument. Rarely do you get credit or a career boost (promotion, raise, addtl responsibility, etc) from the alignment of concerns.

eg Company wants to cut costs. Using AWS can save 60%. Company doesnt want to use AWS because they compete with Amazon. New president oks AWS to save cost next quarter. I told you so gets you nothing.

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

#12
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.

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?"

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

#13
The best "I told you so" is the silent kind.

An "I told you so" is always preceded by a challenge to your authority. The other person should have had reason to believe that you knew what you were talking about, but they foolishly ignored you.

But saying those words turns YOU into the jerk.

It's much, much better to have other people around you judge the situation for themselves and make the determination that you were right.

Even if nobody actually says that you were right and they were wrong, in a healthy organization your respective track records will be noted.

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

#14
Sometimes the best thing that could possibly happen is something not working. How many times did Twitter bump up against its inability to scale on the way to being successful? (Yes, maybe a bad example.) What if someone had said, “Oh it’s never going to scale, we shouldn’t do this“? History has shown that if there is a need or a desire, people will find a way to satisfy it. There are good problems to have and bad problems to have – make sure you are not on the side of trying to avoid having good problems.

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

#15
Usually if an “I told you so” is an option, it means you either didn’t fight hard enough, weren’t convinced yourself, or didn’t have enough evidence to present a compelling argument. If none of those apply, then take solace knowing you’re the best programmer to have ever been and stay silent and humble.

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

#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 corporate workplaces are especially insidious for the original person ever learning anything. The additional work implies a scope change, or tickets slipping into the next sprint, which is implicitly frowned upon. You're supposed to be a team player, so when something does — as predicted — break, you fix it (not the original person) as it now needs to get done, and the company doesn't really care who or how the job gets done so long as it is done. (Or, even, the breakage is in your area of expertise, and even more knowledge — and work — is required to fix it than to have avoided it in the first place, enough so that now you're the one who must take care of it.) But, what has the original person learned? Half the time, even if gently prodded, "Hey $coworker, I've taken care of Y here to fix the Z breakage." is just left unresponded to in chat. Did they read it? Who knows. In person is usually just a "Oh, okay." But do they understand that this is what they were warned about, and that it has cost me time, which causes me to be stressed and frustrated? Who knows. (And all the "emotional intelligence" stuff suggests that one must simply suppress that stress & frustration, as emotion has no place in the workplace.)

But… I do agree that outright saying "I told you so", IME, rarely results in a positive impact. But, I'm not sure what does.

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

#18
I work in storage, and this comes up a lot. I say "It won't reliably hit that target", and people think they know better.

Then it works a good chunk of the time, and when it fails most of the time, nobody is paying attention.

But one day, it doesn't just nip over the line, it hits the wall, and it fails hard in production.

This isn't because I'm bad at making arguments, this is because every software developer has seen a few seconds where their storage device could hit X in a benchmark that isn't applicable, but it confirms their mental model of how this device works.

It takes a long time to actually test these devices well enough to SHOW someone how this will fail, and they'll usually argue with you about how you're wrong for weeks.

Better to just let them note your objections on the record, hit the wall with their face, and then point out your objections were well noted.

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

#20
Blaming the person that could see the issue isn't really ideal here, but it depends if the person stated that will never work without any technical merit or if given a break down of the issues and technical problems but management/leadership ignored it then you're damn right you get to say I told you so, hopefully with a PoC showing that it works with said issue.
Post reply on HN