That’s bullshit.
If I was completely certain of something, I would say so.
In most scenarios, if I’m wrong, I lacked pieces of information. It doesn’t really matter how strongly I feel I am right if I’m wrong. It certainly doesn’t matter how often I am right, because I could get it wrong.
In particular if there is a chunk of knowledge where I don’t know how much information I am lacking, that’s the worst outcome. I could be so extremely wrong that it requires more time than waiting to confirm whether or I am.
It’s very rude and condescending of management and clients to always be so critical of my “confidence.” It has nothing to do with how “confident” I am in an solution.
I get paid to be right. So I will be right a lot. It isn’t a magical he’s usually right so he’s right this time. If that is what is expected of me, us LLMs.
azertyfun@sh.itjust.works 5 months ago
On maybe the third day of my first programming job, a colleague pulled me aside and said “don’t give me ‘shoulds’ and ‘probablys’. You need to sound confident so I can know to trust what you’re saying”.
That guy was a bit of a dickhead in general but there’s a lot of truth there. To the question “what’s the expected impact of this change?”, “None.” is a good answer. “Well it should work…” is not useful feedback and a good Operations Manager will rightfully reject the change.
Of course it is better to be hesitant than falsely confident, but far too many (software) engineers hide behind indecisive language to dodge the necessary hard work of validating their hunches. If you didn’t test your shit fully, just say so. If you’re right, say it. Personal ego doesn’t belong in an engineering discussion.