Transcription
Black text on white background reading “when i say “if i recall” or “if i remember correctly” i am being polite about being right. i remember and i am correct.”
Black text on white background reading “when i say “if i recall” or “if i remember correctly” i am being polite about being right. i remember and i am correct.”
I used to work for a guy who was never wrong. He didn’t talk much but when he did say something, it was always correct. He still hedged a lot, so he would say “I’m not sure you’re right; I think the answer might be X.” What that meant was “You are certainly mistaken and the only reasonable answer is X.”
That’s me in person. Online I’m more likely to offer an opinion on a subject, with a caveat that I’m willing to be corrected. In person, if I speak up, it’s because I am either 100% correct, or I have every reason to believe I am. I don’t open my trap unless I am positive I know the answer.
This is is a remarkably valuable skill, and remarkably rare.
I’ll stay quiet even in that case if it looks like the answer’s close to the surface of the conversation anyway.
My mom’s favorite teaching quote was “it is better to remain silent and be thought a fool, than to open your mouth and erase all doubt”
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.