A month or so ago, I gave a talk at the ACCU Oxford user group on unit testing threaded code. And a long story short, it didn’t go all that well. Initially, I was quite disappointed, and frankly felt like an idiot. The drive home in the car was quite a solemn affair, my friends who’d come with me were being supportive, but that didn’t change the fact that I’d basically delivered a turkey.
I’ve been mulling this over for the last month, and one of the books that helped me a lot was Chris Hadfield’s An Astronaut’s Guide to Life on Earth. And one of the points he makes in the book is to view negative things as an opportunity to learn.
Until recently, I didn’t cope will with negativity. My friends will agree that I’m very harsh on myself and I take things to heart far too easily. So having read Chris Hadfield’s book, I was sufficiently challenged, and decided to take a different approach to this.
So whereas before, I’d have not quite imploded but being glum about it, I decided to view this as a chance to learn. So here we go.
Lesson 1 – Know your subject matter inside out.
Sounds like a no-brainer doesn’t it? But I’d chosen a very complex topic. Probably too complex if I’m completely honest with myself, and what’s worse is that I said it in jest and all of a sudden I was committed to doing it. So lesson 1a, is don’t jest
But I digress. I’m passionate about writing unit tests for code, I think it’s something we should do as developers, no matter what the language we’re coding in. For example at this moment, I’m researching using a PHP unit testing framework.
But unit testing threaded code is hard. VERY hard as a matter of fact. And there was a perfectly good reason Google didn’t return much results, and that’s because it’s not something a lot of people do.
But worse than that, I wasn’t all that familiar with threads either. Sure I have a rudimentary understanding of them, and know enough to be dangerous. And frankly when presenting to a room full of experts, that’s not good enough. It’s bordering on disrespect, so to those who did attend and read this, I’m sorry.
But if you’re going to give a talk on something, make sure that you are fully versed and confident in what you’re going to say. I wasn’t and it showed. Badly.
Lesson 2 – Don’t use an IDE.
Another mistake I made was to have my code in an editor. Not so bad maybe, but unless you plan on doing live coding demo’s then put it on a slide. That way you’re facing your code, rather than craning your neck around to see what you’re doing on the projector.
I found I was doing this a lot, and lost my place a few times because of it. It also involved me dropping out of the presentation software, and in to the code window, which meant a lot of fiddling and faffing about.
So put your code on the slides unless you are doing a live coding demo, or doing a practical workshop or something like that.
Lesson 3 – Keep it simple
We all like to look cool don’t we with our snazzy slides and clickers. But having chatted with Hubert who is a veteran speaker and trainer. He advised that I simply put my slides in PDF.
And that’s good advice. Imagine, you turn up to give your talk, and your laptop goes bang. What if the laptop you borrow doesn’t have PowerPoint? That’s when a PDF is damn handy, especially when you have it on a USB stick. You can give the talk on virtually any computer with a PDF file.
Also Hubert advised that rather than use expensive clickers, I should use my mouse to travel through the slides which is just as effective.
Basically keep it as simple as possible so that nothing overly complicated won’t break things.
Lesson 4 – Seek feedback, the good the bad and the ugly…
After the talk, I felt quite embarrassed, but I knew that if I wanted to get better, I needed to hear the feedback, no matter how bad it was. And I was given it. (Hence this blog post)
Sometimes the feedback you get isn’t what you want to hear. And I’d argue that sort of feedback is the best type. But it’s VITAL that you don’t take that personally. It’s not a personal attack! It’s an observation, and after all if you’ve asked for feedback whether good or bad, then you’ve got to have the stones to be willing to receive the bad as well as the good.
And it’s vital you act on it. Otherwise you’ve wasted the time of the person who was kind enough to give you that feedback. The further consequences then would be that they’ll notice you didn’t act on it, and they’ll refuse to give you feedback in future. And in doing so you’ve cut yourself off from a chance of improving.
Lesson 5 – It happens…
Sometimes, talks just don’t seem to go that well. You could have an off day or something which caused you to lose focus when giving the talk.
And sometimes, that’s how it is. A thousand and one things can cause a talk to nose-dive. The important thing is to recognise this, and not let it get you down.
Lesson 6 – There’s always next time.
You’ve delivered one bad talk. In the grand scheme of things, so what? It’s not life and death.
When Chris Hadfield went up to install the CanadaArm2 to the International Space Station in 1995, he had an irritation in his eye while he was carrying out a space walk to install the arm. His eye starting watering and stinging pretty badly, and in space there’s no gravity for the tears to run away from the eye, it just stays there building up. Right up until it goes over the bridge of your nose and starts messing around with your other eye. On earth that’s no big deal, but in space that’s pretty serious. You can’t exactly open the visor and give your eyes a rub as that’ll end badly for you. Eventually his eyes cleared up, and he finished his work.
But my point is, that one bad talk doesn’t mean the end of your career or anything that dramatic. Sometimes it just doesn’t work out the way you’d hoped. And that’s ok.
As long as you learn where you went wrong, then you can smack it out of the park at the next talk you give.
Lesson 7 – Attitude…
Something Chris mentions in his book (I’m not on commission, honest, but it is a great book!!). When the Soyuz is in orbit, or any solar panelled space vehicle for that matter, it has to turn it’s solar panels towards the sun. This is known as the vehicle’s attitude.
And the same is true for us too. Our attitude dictates how we respond to certain events.
I’ll admit my confidence did take a knock after this talk. But that was a matter of attitude on my part. I could chose to let this crush me, which is what usually happens, or I could decide to use this as a learning experience.
That gave me a fresher perspective and the chance to learn from my errors, rather than risk repeating them again. I can’t recall who said it, but “those who fail to learn from the mistakes of the past, are doomed to repeat them.”
Lesson 8 – There are positives in there somewhere too..
So my talk bombed, badly frankly. But what it did do, was spark an interesting discussion on how we could go about writing unit tests for threaded code, and the techniques that could be utilised.
So even if the talk doesn’t go well, some good can come out of it. And we should remember that as well.
So there we go. I’ve learned a lot from things going wrong, and often times that’s when we learn the most. I have to say that the people at the meeting were very kind and supportive in their feedback, even if it wasn’t what I wanted to hear. (They were far too nice!!) But they were also willing to give support and encouragement.
Initially I wasn’t going to do another talk this year after that one bombed so badly, but I’ve since been encouraged to do another lightning talk, so we’ll see if I’ve really learned my lessons. So watch this space.