Submitting

I have two ways of submitting to CfPs. The first: a carefully written abstract of a talk that I have already prepped, and probably already given.

The second: something that I have already been exploring in blog posts, collected into a “here is this thing that I think I could talk about, but I’m not 100% sure what that would look like yet”.

My submission to mdevcon at the start of the year was of the second variety, prompted by the inclusion of the CfP in an edition of Technically Speaking. It was based on a series of blogposts about unit testing UI code on iOS which had been relatively well read. It included the comment that “this could be either a workshop or a talk”.

Typically I follow a policy of submit and forget – there’s no point getting too attached to these things, you have no control once you’ve submitted, after all.

And then one day an email arrives. And it said – “how about both?”

My reaction: Yay! I was accepted! Both! Ai! Could I? OK then.

Preparing

So I had committed myself to giving my first super technical talk, and my first workshop together, on the same topic, in a two day period. Luckily I had around 6 weeks to prepare.

My initial design constraint was the title: Unit Testing on iOS: Beyond the Model. Clearly there was going to be some overlap between the two, but I didn’t want to just present the same content in two lengths – I think a workshop should be designed differently from a talk. A talk is to give you something to think about, to take back into your own work. A workshop is a deep dive into learning something, I want people to come away feeling like they have conquered it.

I decided to make my talk about what I actually do, not what we might do in a contrived example. Because this, to me, is the main benefit of conference talks – learning what people actually do.

So I opted to tie the talk to my own app, Show and Hide. It’s a relatively simple app UX-wise, the engineering challenges are in the image processing. So I build the talk along the screens, introducing two testing techniques per screen. I showcased my KIF tests by running them – live – using this time to introduce what the app actually does. And I opened and closed with stories about why testing is important and what the ROI is. I used my speaker notes (I write very detailed notes that are easy to turn into a blog post) to get feedback on what people found particularly interesting and what they struggled with.

With the talk mostly done, I moved onto preparing the workshop.

For the workshop, I built a simple sample app of a tic-tac-toe game with a full suite of tests. As part of getting feedback on the content from my talk, I had discovered that people’s knowledge when it came to testing on iOS was widely divergent. Some people were interested because they wanted to know how to unit test UI code… others were hoping to learn how to start unit testing… at all.

This was a huge constraint on the design of the workshop. I added a section in at the beginning covering how to unit test, period. Spent more time on how mocks work. I’ve never been a fan of instructor does something, pauses while everyone has a go, and because experience levels vary so widely, people are either bored or rushed. But knowing that my audience would vary between: no knowledge of unit testing at all, to experts in testing just not of unit testing UI code completely ruled this out as an option. I was not going to start my workshop dismissing half the audience, or boring the rest.

As a result, I put together a ~20 page document that worked through testing the sample app, step by step. With a section at the beginning that could be skipped (unit testing basics) and a more open ended section at the end which I expected only experienced people to get to (getting started with UIAutomation using KIF). I created a fork of the sample project, and deleted tests from it, leaving behind examples and comments on where to insert code. I actually covered more testing techniques in the talk than the workshop – because a deep dive takes a lot longer than an overview.

My workshop was also the first to sell out! Which was exciting but put the pressure on. Thankfully the organisers found me a TA to help.

Final step was a practise talk, where I got some helpful feedback which I incorporated into both the talk, and where applicable the workshop.

Delivering

Delivering the workshop and the talk was intense and exhausting.

The workshop came first. I gave people access to the document, and then moved around the room on rotation, being sure to spend time with everyone. You hear a lot more issues people are facing if you go to them and ask, and there are a lot more opportunities to elaborate and connect with them. Because I had hosted the code on GitHub, and the instructions on GoogleDocs, I was able to make minor changes as people ran into things (thankfully there weren’t many).

Once it was over I was exhausted! I went for food and a walk, unable to contemplate speaking to another human for a while.

Bizarrely when it came to it I was more nervous about the talk than the workshop. The workshop was so thoroughly prepared that I felt like I had ran out of nervous energy doing that much preparation. And I couldn’t think past it being over! So once it was, I felt like I was under-prepared for my talk. Actually I had done about as much preparation as I normally do, I just hadn’t had the emotional capacity to be as anxious about it!

After

When I got the feedback from the workshop, the main comment was that I hadn’t run it in a more typical way – with explanations and breaks for people to try things out. My initial reaction was “but it was designed that way for a reason!” and then I realised – this is a sign of success. If people think that was an option, they must have left feeling their level of expertise – whatever it was (and having spent time with everyone I can tell you it was incredibly varied) – was entirely normal. Really, I would sooner people leave a workshop I ran thinking I’d made a mistake in how I designed it, than feeling stupid because they didn’t know some key concept.

If you are interested in the content, you can find my blog post from my speaker notes here, and an updated version of the workshop for working through at home is available for sale.