Technically Speaking - Anniversary Mentoring

16 Feb 2016 - 746 words

I’ve been reading the excellent Technically Speaking newsletter for a while now and when they announced they would be running a mentoring program, I jumped at the chance and applied straight away. The idea was that each applicant had to set themselves speaking goals or identify areas they wanted to improve and then if you were selected @techspeakdigest would set you up with a mentor.

I was fortunate enough to be chosen and assigned to Cate one of the authors of the newsletter, who is also a prolific conference speaker. As part of scheme I had to identify the areas that I wanted to improve during the hour-long mentoring session, which for me were:

Turning an outline into a good abstract.
Tips for getting a talk accepted via a CFP submission

I’ve previously done some talks and they seemed to be well received, but I wanted to expand the range of topics I talked about and try and speak at some other conferences.

Writing a Good Abstract

At the start of the session Cate looked through an existing submission and offered some advice, which started with the initial comment of:

Good idea, not well pitched

She then went onto offer some really great tips about what conferences were looking for and how I could develop my abstract. I’ve put the rest of my notes below and left them as I wrote them down, so they are a bit jumbled, but they reflect what happened during the conversation!

Tips for an abstract (after reading mine):

Be pragmatic, too much “one true way” can put people off. Maybe a bit too opinionated.
Don’t tie your talk to just one library, might alienate people too much.

Talk outline/structure

Explain - what does it mean to write faster code
Situate - optimisation - what is it? how do you do it? benchmark, etc
Apply - specific examples

Other suggestions

If listeners (or conference organisation committee) agree with your assumptions, they might be more likely to choose your pitch

Be careful about being too specific in the abstract
Don’t put too much in the abstract, leave some specifics out

be compelling, but a little big vague

1 or 2 examples of what not to do is okay, but must give them something to do afterwards, otherwise you could put them off.
Broad v. Narrow talks
- Most conferences will want “broader talks”
Bio is pitch for you
- Abstract is pitch for you talk

Finally, as well as offering general advice, Cate also took the time to help me re-write an existing abstract I’d put together. I’ve included the “before” and “after” below, so you can see the difference. Whilst it’s hard to see someone pick apart what you’re written, I do agree that the “after” reads much better and sounds more compelling than the “before”!

Before

Microbenchmarks and Optimisations

We all want to write faster code right, but how do we know it really is faster, how do we measure it correctly?

During this talk we will look at what mistakes to avoid when benchmarking .NET code and how to do it accurately. Along the way we will also discover some surprising code optimisations and explore why they are happening

After

Where the Wild Things Are - Finding Performance Problems Before They Bite You

You don’t want to prematurely optimize, but sometimes you want to optimize, the question is - where to start? Benchmarking can help you figure out what your application is doing and where performance problems could arise - allowing you to find (and fix!) them before your customers do.

If you aren’t already benchmarking your code this talk will offer some starting points. We’ll look at how to accurately benchmark in .NET and things to avoid. Along the way we’ll also discover some surprising code optimisations!

The End Result

After the mentoring with Cate took place I was accepted to talk at ProgSCon London 2016, so obviously the tips and re-write of my abstract made a big difference!!