After I published test && commit || revert, I got a variety of responses on Twitter and on Hacker News. The Twitter comments were mostly of the form, “I’ll try it and post how it goes.” Many of the Hacker News comments were objections–“This won’t work because…” I was reminded of a habit: turn objections into goals.
(My inspiration for this technique came from Dale Emery and his “Resistance as a Resource”.)
I turn objections into goals when an idea provokes resistance. My natural tendency is to argue or get angry. If I can insert a little logic between seeing the resistance and reacting, though, I can offer a more productive response.
But First..
Before deciding to engage with an objection, I need to decide what I think is meant by the objection. Sometimes objections mean just what they say–this won’t work because of that. And they are right. Sometimes objections mean rejection–I’m not ready to even think about this idea now. Those objections aren’t worth responding to at the level they are posed.
If I read an objection as engagement–interesting, tell me more, I’m worried about this–then engaging back has some upside.
“Can’t X because Y” -> “Can X when not Y”
The first step in objections as goals is to invert the statement, make it positive. “I can’t make changes in small steps because sometimes I have to change a hundred files,” becomes, “I can make changes in small steps when I can change one file at a time,” or, “I can make changes in small steps when a single change can modify a hundred files.”
This transformation is not logically sound. There may be other reasons I can’t make changes in small steps. It’s okay. We aren’t pursuing certainty here. We are trying to help people through the barriers to their own learning.
Sometimes this transformation is all that’s needed. The other party is saying, “I don’t want to try and fail.” We respond with, “So maybe trying isn’t so bad.” Away they go, ready to try. That’s all the good we can do for today.
There may be juice in the lemon for us, though. A little more work uncovers it.
“When not Y then X”
Objections can contain information we didn’t have or that we weren’t prioritizing. The second transformation transforms this information into something we can use.
From the example above, we go from, “I can make changes in small steps when a single change can modify a hundred files,” to, “When I can modify a hundred files with a single change then I can make changes in small steps.” Oh. Okay. That’s a thing I might do.
Examples
Here are some worked examples from the comments on test && commit || revert.
- I can’t use TCR because nobody will write tests. I can use TCR when people write tests. People writing tests lets me use TCR.
- I can’t use TCR because I like to see my tests fail. I can use TCR when I don’t need to see my tests fail (or perhaps “…when I can still see my tests fail”). Confidence that my tests are sound let’s me use TCR.
- I can’t use TCR because the tests are slow. I can use TCR when the tests are fast. Fast tests let me use TCR.
- I can’t use TCR because it results in a fragmented commit history. I can use TCR when it results in a sensible commit history (or “…when I no longer care about the commit history”). A way to track change strategy separate from change history lets me use TCR.
Conclusion
The first time you turn objections into goals is likely to feel awkward. I’ve been practicing for ten-ish years and at some point it just became automatic. Someone has to object pretty hard and personally and I have to be off my game for me to drop into defensiveness in response to an objection. It still happens, but more often I offer help and learn something in the process.
Any objections?
