Learning
Scientific Method
A good explanation should risk being wrong. Make a prediction, test it fairly and let the result change what you believe.
- Question
- Predict
- Test
- Observe
- Revise
A question leads to a prediction and a test. Observations return to the explanation, which may be kept provisionally, narrowed or revised.
What would show that your explanation is wrong?
You keep losing a position and decide that your grip is the problem. Maybe it is. But what would you expect to see if that explanation were true? And what result would make you reconsider? Asking those questions turns an appealing story into something you can investigate.
A scientific approach is more than collecting examples that agree with you. It asks for a clear claim, observations that bear on it and willingness to revise. Science does not have one universal recipe shared unchanged by every discipline. The Stanford Encyclopedia of Philosophy's discussion of scientific method describes a much more varied history. Here, we borrow practical habits of careful inquiry for coaching, not the authority of a laboratory.
Make a small prediction before the round
Suppose the claim is that one familiar grip gives you room to turn in a particular control. Predict what should change when you use it: the relevant pressure should move enough for the turn to begin. Agree with your coach on an appropriate way to compare attempts. Keep the starting position, task and partner's resistance reasonably similar.
Record whether the predicted change happened, not only whether you escaped. An escape could happen because the partner changed position for another reason. A failed escape could still show that the grip created room but a later part broke down. Separating the predicted effect from the final result makes your explanation more useful.
Try the alternative too. Does another grip do the same job? Does the supposed improvement disappear when the partner keeps the pressure? Ask for help interpreting what happened. A coach may notice a variable you did not know existed. You are testing a bounded question, not trying to settle the best escape for everybody.
Be fair to the answer you do not prefer
Change one important feature at a time when that is practical, but do not claim perfect control. Partners learn, fatigue changes and resistance is hard to match exactly. A few rounds can suggest a useful adjustment without proving a general cause. Repeat a promising comparison and try it against another appropriate partner before becoming too confident.
Decide what counts as useful evidence before you see the result. Otherwise every success becomes support and every failure gets explained away. Confirmation bias is especially tempting when you like the technique or the coach who taught it. Being wrong about an explanation does not mean the whole session was wasted.
There are also questions you should not investigate by creating unnecessary danger. Do not test unsafe contact, push through injury or withhold stopping signals to see what happens. Find a safer way to examine the idea with qualified guidance, or leave the question unanswered. Curiosity does not override partner consent.
Keep a brief note: the claim, your prediction, what you observed and what you would change next. If the evidence is mixed, say so. Updating the explanation is the work. The aim is not to prove you were right, but to leave the next practice with a better question than the one you brought in.
Sources and further reading
- Stanford Encyclopedia of Philosophy: Scientific Method
Philosophical and historical account of scientific methods. The small training comparisons are practical inquiry, not formal experiments or established sport interventions.
See an idea alongside another
Related models
Confirmation Bias
Look for the result that would challenge your favourite explanation.
Bayesian Updating
New observations should change confidence, not automatically settle the question.
Feedback Loop
The next attempt becomes useful when the observation actually changes the plan.
First Principles
An explanation of the task's requirements still needs checking against what happens.