Forget “affirmative voice” for a moment, since that seems to be tripping others up as well as you. Prompt Engineering suggest sounding like the LLM, asking questions with “the same voice” as the one the LLM uses to respond. Perhaps PE needs to clarify this with some examples, because calling it “affirmative voice” hasn’t seemed to make it clear enough.

I suggest asking them, then perhaps sharing what you learn for the benefit of other folks who are similarly confused.

The only interpretation that comes to my mind is avoiding “not” and “don’t”. Ask for what you want instead of what you don’t want. 🤷 That’s just a guess.

I’m enjoying being told about these counterexamples, as I’m seeing even more clearly how this attitude is embedded in our shared culture.

So far, all the specific contexts people have mentioned to me in which men are being told to smile is one in which others feel entitled to the man attempting to impress them. In contexts such as dating or performing on video or working in retail, this doesn’t particularly surprise me.

I suppose another reasonable context is one in which the people asking you to smile are genuinely worried about your emotional state and want you to seem happier. By chance is it typically like that for you? (Let’s set aside for now the complex matter of whether they actually want you to feel better or they merely want to control your behavior or feel less uncomfortable themselves.)

How interesting! That makes it even less surprising.

That’s one exception that doesn’t surprise me. Do you have any sense of how often they are doing this with intentional irony compared to with genuine obliviousness?

Tell us a story of the last time you witnessed someone telling a man to smile because he would look so much better if he did.

I can’t, either. That’s why.

Think of the people who seem to do this to you. Pick the one who trust the most. Now ask them.

Which kind of “best” is your “best”?

A group of people who are tired of your unjust bullshit, who are not going to let you shrug it off or get away with it, and who are not going to stop confronting you with it.

Indeed, this is a time for naming conventions that communicate the details that the type system can’t clarify. This leads to the long names that senior programmers make fun of. Don’t listen to them; let them laugh then make this kind of mistake.

Wow. I love that story and I’m glad nobody was hurt.

I wonder whether that happened as a result of unexpected behavior by the pitching machine or an incorrect assumption about the pitching machine in that coworker’s tests.

I find this story compelling because it illustrates the points about managing risk and the limits of testing, but it doesn’t sound like the typical story that’s obviously hyperbole and could never happen to me.

Thank you for sharing it.

This seems to happen quite often when programmers try to save time when writing tests, instead of writing very simple tests and allowing the duplication to accumulate before removing it. I understand how they feel: they see the pattern and want to skip the boring parts.

No worries. If you skip the boring parts, then much of the time you’ll be less bored, but sometimes this will happen. If you want to avoid this, then you’ll have to accept some boredom then refactor the tests later. Maybe never, if your pattern ends up with only two or three instances. If you want to know which path is shorter before you start, then so would I. I can sometimes guess correctly. I mostly never know, because I pick one path and stick with it, so I can never compare.

This also tends to happen when the code they’re testing has painful hardwired dependencies on expensive external resources. The “bug” in the test is a symptom of the design of the production code. Yay! You learned something! Time to roll up your sleeves and start breaking things apart… assuming that you need to change it at all. Worst case, leave a warning for the next person.

If you’d like a simple rule to follow, here’s one: no branching in your tests. If you think you want a branch, then split the tests into two or more tests, then write them individually, then maybe refactor to remove the duplication. It’s not a perfect rule, but it’ll take you far…