One sentence I want more engineers to say out loud: I do not like this.
Not as taste. Not as politics. Not as passive-aggressive code review theater. As an engineering signal.
I do not like this because rollback is unclear.
I do not like this because the test verifies the mock, not the behavior.
I do not like this because we kept scope, deadline, and quality fixed, so the risk moved somewhere invisible.
I do not like this because we are selling a failure as a success story.
That is why Brene Brown and Adam Grant's discussion about BS disclaimers landed with me.
No offense, but. I do not want to be critical, but. Everyone is saying.
These phrases often try to do two things at once: make an objection, and avoid owning the objection.
Software quality does not improve through invisible armies.
It improves when someone is willing to name the concern clearly enough that the team can inspect it.
The point is not to be rude. The point is to be accountable.
If you do not like something, say it.
Then do the engineering work: what property is violated? What evidence do you have? What risk does it create? What decision do you want?
That is the communication skill I care about teaching engineers.
Not sounding confident. Making the concern useful.