It occurred to me the other day that there's more than one thing professional programmers can learn from kinky people: we can learn how to ask things of our peers.
The first thing the kink community taught software developers (and other groups) is the code of conduct. Kinky people have been dealing with offensive, intrusive, and disruptive conduct within our public spaces pretty much since the founding of the modern community in the late 1980s. We know how to manage that stuff. The very first codes of conduct for software conferences were written by a kinky person cribbing off an S&M dungeon's rulesheet, and many of the codes of conduct for all manner of conferences and conventions since have descended from her work.
The other thing kink can teach software developers, the thing they can use every day, is the Consent Communication Pattern. The consent communication pattern is how kinky people ask for specific things. It's extremely useful; you might even call it "manipulative," in that you're much more likely to get what you want if you use it versus the more common ways of approaching someone and making a request.
The consent communication pattern is so useful that my children's school district teaches it to seventh graders in their sex education curriculum. It's ridiculously simple, and has nothing to do with sex. Ready?
Concrete context. Concrete request.
That's it. In sex ed classes, the pattern is used to help people negotiate relationships and specific activities that happen when dating. The examples from my school district's workbook read:
* "I really like when we X. Can we do more of that?" * "I really don't like when you X. Could you not do it?" * "I really don't like when you X. Could we do Y instead?"
The working examples are innocuous, things like "Hold hands in public," or "Call me by than nickname," or whatever. But you can see where the textbook really wants to go.
The listener to this request is actually free to negotiate. In the latter two examples, the person making the request is setting up a boundary, a limit on what he or she will accept. But in all cases the listener can make specific counter-proposals in order to get his or her desires met.
In my time as an engineer, I've been the recipient, and sometimes the deliverer, of an awful lot of bullshit passive-aggressive "asks." Questions to the team of "What are we doing to hit the deadline?" are in this category; there's an implicit aggressive "We're not doing enough, but it's not my fault we're not doing enough" in the question. "We don't know enough to move forward" is in the passive mode, in that the person saying it is implicitly asking the others for help, but hasn't come out and said so.
In English, we learn about subject-verb-object relationships in sentences. But conversations don't have subjects; they have topics, and often subtopics. The consent communication pattern establishes a topic, and then makes specific requests of people for information or action about that topic. It works with the human mind's fast-and-slow thinking patterns, giving the listener time to accept the topic, switch their mind to deal with it, and then drives their ability to respond thoughtfully and coherently.
The user story template is an example of a bullshit ask. "As a [role], I want to [do something] so that [reason/benefit]." It has a template, but it has no concrete request. I know, we're supposed to assume that the request is, "Can you do that?" But it's still a bullshit, passive-aggressive request.
The next time you're at a planning meeting, re-write them in a hyper-concrete form: "The customer needs to be able to do X. Do we know enough about X to talk about a solution?" And then, "I know estimates are only estimates, and these may be harder than they look, but can you give me initial estimates for how long each task will take?" Notice how the pattern sets a concrete topic and then makes a specific request.
One important aspect of the consent communication pattern is its concreteness. If you can't establish an specific context and craft a request that's attainable and relevant to the context, you don't actually have a request: you have a vague feeling that something is wrong, and you want the other person to help you figure out what that something might be. And that's fine! But you should back up say it that way. "I've been reading over X, and I have a feeling that something is wrong with it. Can you help me understand it better?" Note that the request is concrete, attainable, relevant, and open ended. While it does have a "yes" or "no," it's worded in a way that leads to further conversation. If the request were worded, "Do you feel the same way?" someone already pressured by time and responsibility might not give you the conversation you're looking for.
Programmers are a notorious bunch for having ADHD and other neurodivergencies. The consent communication pattern works with the programmer's brain. A request without a topic just... is. It exist without any surrounding context. People, especially those for whom context is difficult, are much more willing to jump in and respond to requests when their brains aren't being racked with the effort of trying to make sense of the context.
Hanna Thomas recently wrote:
Agile is described as a mindset. But let’s call it what it is and skip the middleman. Successful organisations aren’t ones that adopt an ‘Agile mindset’. Successful organisations are ones that adopt a feminist, queer, anti-establishment, progressive mindset — one that is flexible, experimental, pushes boundaries, self-organises, and acts in service of community.
I'd add "kinky" to that list. Kink has a very strong ethos of respecting other people, both their wants and needs and their boundaries and limitations. Kink has a strong, evidence-based and experience-driven system for creating safety, enabling personal growth, and asking for potentially personally embarrassing or emotionally vulnerable moments in public spaces where deeply intimate and possibly dangerous things are happening. If we can do it where intimate or physically risky things are going on, then software developers can learn to do it in a professional space that (I hope) is not quite so intimate, vulnerable, or physically risky.