For our first “practice run”, we prepared demonstration code and tests based on the Bowling Game Kata and presented it to a group of fellow ThoughtWorkers. We demonstrated the tests running, and at the request of the audience, changed the code to break one of the tests and demonstrate the error messages.
Feedback from the group was that the pace of the presentation was fairly fast, and the most exciting bit was when we actually changed the code “live”.
More recently, our team on my current client were asked if we might be able to fill in for a lunchtime Tech Talk at short notice, so I dug out the Jasmine presentation again (sadly, I had to do it without Rachel, since she is thousands of miles away enjoying the delights of Bangalore as a trainer at ThoughtWorks University!)
With only a few hours to adapt the presentation, I decided based on the previous feedback to write all of the code and tests during the presentation. Brave maybe, slightly reckless and risky for sure! I ran through the code I planned to write only once with another colleague Chris, and stumbled in a number of places, particularly in the code I wanted to write to demonstrate Jasmine spies, but overall I was happy that it would be good enough. I also decided to try and recruit audience members who might be willing to write some of the code for me.
Learnings from how it went
Overall, I was happy with the decision to code live – the first half of the presentation went very well. When I reached the code around spies, the tests went red and I was unable to multi task well enough to keep presenting, see the bugs and fix them and the tests so I abandoned the real code and carried on, using just the slides and test code. I also received feedback that suggested that the action of writing tests first was a powerful demonstration of test-driven-development, which was also something that was interesting for the audience.
I also found it very difficult to keep talking and keep it interesting while I was either writing code or somebody else was writing a test, so there were a few short silences.
Lastly, I was aware that some of the code I was writing was not optimal, but I didn’t feel that I had the time or enough focus to refactor it (particularly when it wasn’t working anyway).
I think the presentation would work better with two people and a little more practice of the code. This way, one person could talk while the other focused on writing a test or making it pass. However, I would definitely keep the live coding aspect.
I fell back on the short preparation time as an excuse when things didn’t quite go to plan, but I hope a development audience would usually be fairly forgiving if you can’t quite write code right first time around!