Testing examples that do match your mental model only proves your model partially matches the actual model, but it does very little to actually identify misunderstandings, or improve your understanding.
But if you don't have (or want) callers that depend on your specific behavior in error situations then I wouldn't bother testing them. It's my contract that I can and will change the behavior arbitrarily and you can't be mad at me for it.
You'll need to paste this snippet into the JS console in your browser (or make a bookmarklet out of it and click it in order to reveal the article) because something on nytimes.com has caused it to break at some point in the last 8 years:
document.querySelector(".g-result.g-noText").style.display = "block"
HN comments: <https://news.ycombinator.com/item?id=9818310>Of course, there is this counterpoint...
To which, the reply might be roughly the same but ending with "We should add a nullable field to the greeble table and then create a migration."
If the proposer is paying attention, they might say "no no, the new field has to go in the widget table."
The goal isn't to catch someone out, but to make doubly sure you've reached a shared understanding.
It's a bit like writing unit tests that fail, before you implement the change that'll make them pass.
"No, it looks more like it's a routing issue. The endpoint never gets hit when the client sends data, so we're trying to troubleshoot where the disconnect happens"
Not trying to be snarky; just had a real world example handy because my entire team uses this type of messaging. Usually starts with a "okay, just trying to level set...", or "just so I know I'm on the same page".
In our experience, this type of communication has helped minimize instances of completely mismatching on task expectations
Really no wrong answer, so long as all parties are earnestly working towards the solution. The nice part about this strategy is it lets your 'most correct' answer actually be multiple answers that you whittle down, rather than making the judgement calls, yourself, on what the other person most probably means to what they least probably mean. You remove an assumption and lead with your biggest concern, even if that seems like a crazy suggestion. Once you confirm that it is crazy, you're closer to the target. And if the 'crazy' thing was right, then you get to skip a lot of the steps between your initial best understanding and the correct understanding.
Great teams are the ones where no one has to preface questions with this sort of throat-clearing remark (and so they don't).
If it's a senior developer, then they should feel comfortable speaking up when there's a disconnect or misunderstanding. I would argue that one trait is the overwhelming majority of what separates a senior developer from a junior one.
Whether seniors feel confident to correct the manager depends primary on how manager acts when corrected. There are many managers who don't get corrected by seniors and seniors who do learn not to do that - either becabuse it is useless or will be punished.
Either way, juniors do talk with management fairly often, whether they have responsibility or not.
Seems like it'll always be the case that people will chuck the responsibility for X towards people with the lowest capacity to actually be responsible for X
People feel fine with correcting managers when managers reward being corrected instead of punishing it. That's got nothing to do with seniority levels
this is just idealistic and doesn't acknowledge the power dynamics in any organization, nor does it factor in peoples' individual personality traits.