Inversion

Goals are important. Knowing what you’re doing and why can help clarify things when you need to make a decision. Turning that around helps. Knowing what you’re not going to do is just as important.

Sometimes questions are like that too. Ask a question one way and it can be hard to answer. Invert the question and it can be a lot easier. Consider the following question:

Which one of the following does not have an integer cube root?

1. 216
2. 27
3. 1331
4. 700

The naive way is to calculate the cube roots and see. If you have a calculator that’s easy. Without, not so much. On the other hand, it’s relatively easy to calculate the cube of a number. If you change the question to which numbers are perfect cubes you can quickly come up with this table

1 -> 1
2 -> 8
3 -> 27
4 -> 64
5 -> 125
6 -> 216
7 -> 343
8 -> 512
9 -> 729
10 -> 1000
11 -> 1331

And see that 216, 27, and 1331 are perfect cubes, so 700 must not be. 

You can apply the same kind of question inversion to other things as well. Like debugging. When debugging the first question is usually “Why did that break?”. Often it’s helpful though to first go through the “How is this supposed to work?” cycle first. Especially if it’s an area new to you. 

Maybe performance is your thing. In performance, you normally ask “How can we speed this up?”. But maybe what you really need to do is to keep things from slowing down. That’s a different question, and the answer might be very different.

Really, it’s about perspective. Having the right one at the right time. Because how you look at things will influence how you see them. And how you try to change them.