One of the things that I’m learning while working at ThoughtWorks University is to bite my tongue a bit to allow people to learn in their own way.

I noticed this particularly yesterday in a refactoring session we were doing.

For about 10-15 minutes in the middle of the session we’d managed to get the code into a state where it didn’t compile and we couldn’t run the tests.

The 'natural' inclination in that situation for me would be to step in and impart some 'wisdom' about the importance of taking small steps while refactoring.

Instead we kept on going for another 10 minutes or so until one of the guys pointed out that the code hadn’t compiled and nor had our system test been run for quite a while.

With some prodding from Frankie the pair at the keyboard made some temporary changes to the application so that it’d compile and then completed the rest of the refactoring in a more incremental fashion.

Of course the other side of the coin is to ensure that I do actually give some input when it’s useful.

The key here seems to be to ensure only to give enough input for the situation.

I’ve learnt quite a lot about some topics and with the amount of stories I’ve picked up and the analogies/metaphors I’ve picked up it can easily become a brain dump if you’re not careful.

From my own experience this style of receiving information isn’t particularly easy to digest, especially if you don’t have any context to link the stories to.

The other danger with telling stories is that one story can often trigger another trainer to tell their own story and before you know it 30 minutes has gone by and the original point has long been lost!