When I became a swimming trainer, I had to learn various ways to teach kids how to improve their swimming strokes. As part of a seven weekend education course, we not only heard about stuff, but also had to give training lessons to our classmates that proved that we were eligible to the trainer certification. In these courses I learned about a gentle technique that I lately noticed to apply in other fields as well – whether appropriate or not.
Over-correction in swimming
Say, you have a swimmer that is turning his whole body during crawl swimming when taking in breath. That’s terrible, since the swimmer will lose lots of momentum. He is rolling his body too far. The whole arm movements won’t be as effective as they could be in the water.
Another swimmer does not apply a wave movement on top of his body during breast-stroke. He will be losing momentum constantly, since his legs will slow him down way more than necessary. The same goes with the arms when he brings them back in the starting position.
What do you do as a trainer? You need to correct that movement. The easiest way that I learned was to over-correct the situation. In the first example, I would ask the swimmer to turn his head to a point at which he can barely take in air from above the waterline. I often asked kids to turn their heads just as high so that they could barely see the benches outside the water – but no higher. For the second example, I would incorporate a training lesson with various coordinative exercises. I would ask kids to swim a wave, then add the arms, then eventually add the legs – maybe with many more steps in between, depending on the particular group I was training with.
The technique is called over-correction. You over-compensate a wrong movement in the other direction for a limited amount of time. Then you go back to “normal” swimming, and the movement has shifted a bit. You do this over and over again to make a better movement stick.
I used this technique quite lots of times. Whenever I noticed there was something wrong, I planned in exercises for the training group that would correct some of the major errors. Notice that we also learned “movement sight” during the seven weekends. That is how to spot that something is wrong, to notice the wrong turn in the movement while observing the swimmer closely. Only when you directly see what goes wrong, you may provide corrective feedback after the swimmer finishes the lane. Or you can help the swimmer with exercises to over-correct. In either case, you need to spot the problem first, and then understand it well enough.
So, vision, feedback, and over-correction form a vital training package.
Over-correction in professional life
In software development I noticed the same technique applied by others. For example, take Michael Feathers’ book Working Effectively With Legacy Code. He provides a set of rules for unit tests in it:
A test is not a unit test if:
- It talks to the database
- It communicates across the network
- It touches the file system
- It can’t run at the same time as any of your other unit tests
- You have to do special things to your environment (such as editing config files) to run it.
If you apply these rules without thinking, then you might start to wonder how you can test a class that is a network adapter for your application. Or how do you test the component that writes data to your disk, and will be used all over the place? A few years back, I asked Feathers, and he replied that he wrote down those rules at a time when developers would only test their code with integrated tests, rather than simple unit tests. He wanted to change that. (According to my experiences this is still the case.)
Clearly, he used over-correction to kick programmers out their comfort zone to think from a different perspective again.
Or take Lessons Learned in Software Testing. That one has a couple of contradicting lessons. For example, lesson 145 is titled “Use the IEEE Standard 829 for test documentation” while lessons 146 (the next one!) is titled “Don’t use the IEEE Standard 829”. That’s not to drive you crazy. It’s there to make you think. Think about your problem from a different perspective. It’s an over-correction – as I would call it.
An honest correction
As a trainer, coach, and consultant, I lately noticed that I use that technique a lot. Probably too much. When I say that programmers should start to test, I say that because I have made the best experiences with cross-training people in up- and down-stream activities.
At the local shop I once worked (for ten years), I knew how to do the cashier, I knew how to deal with vegetables, but my main activity was ordering of beverages, beer, wine, and liquor. I could contribute in other ways since I knew all this stuff, from product ordering, to the shipping process to how it is sold. I could jump in when there was trouble in any of these activities, and I could quickly evaluate the current situation, and jump in.
The same serves us in software development. If we know just enough to compensate for bottleneck situations, or when a colleague won the lottery and left the country for greener pastures, we are able to contribute more meaningfully.
In the past two weeks, I probably drew some false dichotomies. That was just to make you think. Of course, it might be the case that you need to develop some other skills like “movement sight” to spot a problem when it occurs, and the power of providing feedback in order for your colleagues to hear what you are trying to say. I will leave those ones for other blog entries.
