Conclusively demonstrating why you should listen to others…
I can change the rate at which I learn things. So can you. It doesn’t depend on topic or natural inclination. It doesn’t depend on intelligence. It’s all in how I set up my learning experience.
I am not a professional instructional designer but I pair with them. I am a professional coach. And I am a professional learner. Here are the techniques I use to learn, instruct, and coach more effectively. I hope you find them useful. Continue reading “Learning faster and more deeply”
Someone I know had the following conversation recently during code review:
- [WontFix] //depot/[elided].cs: Line 232
- [reviewer]: Unit test this directly
- [author]: the integrations test this. Don’t see any direct benefit of UT it directly. (26 minutes ago)
He wanted advice on how to get past this. His goal is to get his team to write direct unit tests, as opposed to multi-unit component and integration tests. But how? And what does he do in code review to help the team accomplish that in specific cases? Continue reading “Using code review to support change”
I see pairing as similar to a language. So I figured I’d put together a phrasebook for those who are just learning to pair. You might find these useful as you are trying to locate the bathroom, train station, and restaraunt in PairingLand. Continue reading “A Pairing Phrasebook”
I have noticed a significant difference in the results achieved by teams with pairing depending on how they approach learning to pair.
In particular, many people don’t expect pairing, itself, to be a skill. They don’t realize that they’re going to have to learn new ways to think, to problem solve, to be creative, to filter their perceptions, and even to converse. Since they don’t realize this, they get surprised. And then they set themselves up to make that learning hard, and quit when they get poor results and find pairing to be hard while learning. Continue reading “Is Pair Programming for Me?”