I hate hello-how-are-you-then-wait-before-asking messages as much as the next autistic programmer, but both examples in the "more examples" section still kinda read like an asshole, because they present as fact things that often either aren't, or you couldn't be absolutely sure of it.
For instance:
> "The caching layer is causing a 400ms overhead on cold requests. Here's the trace."
Cool, but how do you know that? Are you sure you're interpreting the trace correctly? How many measurements have you done? Sure that there isn't a historic reason why the caching layer behaves in this way, or a conflicting requirement that lead to choosing this latency over some other, worse consequence?
In the same way:
> "The current error handling swallows exceptions silently, which is making debugging hell. We should propagate errors to the caller"
Agree in principle, but did you check git blame to see if there was a rationale? Or asked someone else? How much change would this require? Could it break consumers of our code?
Granted, the "polite" messages didn't care any of this information either, but at least they didn't almost preemptively shut down the conversation by laying down what is at best an well informed guess and at worse purely personal opinion as if it's irrefutable truth.
Perhaps instead of debating whether to be (too?) polite or direct, it's better to focus on providing as much information as you can, anticipate follow up questions, and close with clear actionable next steps, something which is also missing from both versions of the messages.
"Well, those are hypothetical examples" cool, another evidence that we're all talking out of our asses about the sex of the angels, here. Maybe if the author didn't try so much to characterize themselves as perfectly infallible information delivery machine, then I wouldn't have nit-picked so much their half-assed hypotheticals.
For instance:
> "The caching layer is causing a 400ms overhead on cold requests. Here's the trace."
Cool, but how do you know that? Are you sure you're interpreting the trace correctly? How many measurements have you done? Sure that there isn't a historic reason why the caching layer behaves in this way, or a conflicting requirement that lead to choosing this latency over some other, worse consequence?
In the same way:
> "The current error handling swallows exceptions silently, which is making debugging hell. We should propagate errors to the caller"
Agree in principle, but did you check git blame to see if there was a rationale? Or asked someone else? How much change would this require? Could it break consumers of our code?
Granted, the "polite" messages didn't care any of this information either, but at least they didn't almost preemptively shut down the conversation by laying down what is at best an well informed guess and at worse purely personal opinion as if it's irrefutable truth.
Perhaps instead of debating whether to be (too?) polite or direct, it's better to focus on providing as much information as you can, anticipate follow up questions, and close with clear actionable next steps, something which is also missing from both versions of the messages.
"Well, those are hypothetical examples" cool, another evidence that we're all talking out of our asses about the sex of the angels, here. Maybe if the author didn't try so much to characterize themselves as perfectly infallible information delivery machine, then I wouldn't have nit-picked so much their half-assed hypotheticals.