It’s been an interesting few months since I last wrote anything here. Apart from a fairly hectic project in work, my wife is re-training as a software developer and so I’ve been able to find out many ways in which I am deficient as a teacher. The teachers on her course have done a good job in bringing her to the position where she can quite happily code away on server-side code or Android applications, and it’s only when I try to answer one of her questions that I realise how hard it is to teach someone who has some knowledge and not much experience, relatively.
So, I’ve decided to write a series of posts that cover some basic topics but which – crucially – I never see being used out in industry. This is as much a way for me to learn how to talk at the correct level as it is to pass on technical information – hopefully, both parts will be successful. And so to business, with part 1 – A good, lazy way to write tests.
Interesting post and very apt topic. But I think with some practice it is possible to become a good teacher.
One particular example with technical people, is that of our documentation. We tend to write documents in a rather selfish manner (I am certainly guilty of it many times); we communicate in textbook-style, with much left to assumption. We tend to communicate more for ourselves, than for others. IMHO it is when we focus more on our communication in terms of its consumption by others, we start to bridge this gap.