So you've submitted an abstract

You've thought hard about your conference talk ideas; you then fleshed out your idea and worked hard on an abstract; and finally you plucked up the courage to make the submission to that big conference.

What next?

Keep momentum.

#physics

It really depends on the style of your talk, but in most cases, just keep whatever momentum you have (or had back in December), and work on it in some form every week.

Wait, abstracts closed. Public voting complete. Aren't I just waiting for a March notification before I bother starting?

No.

There are a few reasons you could be working on your talks each week. For instance:

1. Rome wasn't built in a day - it depends, but a reasonable talk should take at least 20 hours to develop, plus the time needed to gather the experience the talk represents, past, present, or future. Presentations left to the last minute can look & sound like it. Presentations started early will have time to cultivate, allow your ideas to progress as you write up progress so
2. Experience - even if your talk isn't accepted, you have gained the experience necessary for a topic you've considered worthy enough to talk about it. Maybe you've already gained the experience, but compiling your thoughts will help you gain a deeper understanding of the topic.
   Maybe you gathered a few important insights along the way.
3. Aim high - OK, maybe you end up getting a "sorry, not this time" email for the big conference. So what's happening locally? Do you have a regular meetup nearby? Is there another conference where this talk would fit well? Would the team at your current workplace benefit from listening to your talk for an hour? If you write it, people will come.

And as an extra tip 

• Transform your speaker notes into search engine fodder
  I need to do this more often. I've seen more organised folk post their notes on GitHub, or as some sort of blog post. As a developer, sometimes I stumble across a great set of slides, but yearn for a little more context or content. It will always be useful for somebody, won't hurt your SEO, and you'll thank yourself immediately, and again in 6 months time when you google your own post.

How am I tackling my own submissions?

Slow at first, it's been a busy summer, but now I'm back at work building things, I feel like getting back into regular time aside.

I've submitted four ideas, to help my chances of being accepted. Maybe one idea is really good, but every other Tom, Dick, and Henrietta has submitted some variation of that idea. Perhaps your secondary submission fits rather well instead, among all the rest?

And given the thoughts above, I could make progress on all these ideas, knowing that they'll be useful somewhere along the line. Our local user group always seem happy to have me yak on about APEX.

Anyhoo, these were the titles for my Kscope20 submissions.

• Oracle Reports to AOP Case Study
• Visualising APEX Performance Monitoring
• Navigating APEX Version Upgrades
• A Practical Guide to APEX Authorisation Schemes

I was involved in the public voting exercise, and I not only saw some similar submissions, but a whole bunch of submissions on ideas I've considered, had, or wished that I had. Even if only a third of those submissions ever get produced, there's going to be some amazing content out there.

My titles are a little utilitarian, and lack some awesome word play I saw when reviewing abstracts, but I'm pretty excited about the building the content.

What am I doing to prepare these? I haven't got to this yet, have I?

• AOP - I strategically chose this topic as I'm learning this as part of business as usual at work. My aim is to present a cheat-sheet style session to help new AOP developers hit the ground running. All I need to do is show up to work each day to prepare, though I need bed down the session structure.
• APEX Performance monitoring - I've been writing charts & reports on these log tables for years, and I have the confidence I can piece together this presentation at will. I've offered different formats, so it may even be hands-on.
• Version upgrades - I've done a few of these over time, and I've been making notes. I need to start playing on an empty canvas to help cultivate exactly how it will play out.
  And by this I mean probably both a simple text file that slowly fleshes out a list of key items I want to cover, and some sort of scratching/drawing the represents the story of my talk.
• Authorisation Schemes - this one's been a real slow burn, something I've been wanting to do for a long time, but I hope to turn this into more than just a presentation. This is what I've been hinting about in this sites left menu bar, some form of publication.
  After piecing together a fairly clear breakdown of content, I may have procrastinated a little.

Regardless of where my experience is coming from to formulate the presentation, I typically start with a simple text file, flesh about my ideas, reorder as necessary, then start my slides.

Once the slides are done, I tend to go through them a few times, with a text file ready to note down simple modifications I want to make, without disrupting my flow too much.

Rinse and repeat, until your practice in front of a mirror/camera/friend comes out smooth, and on time.

Don't worry if you get nervous. We all get nervous.

PS - some of us have been living under metaphorical rocks, so if you've missed a bunch of posts by Martin Widlake on presenting, I recommend you check them out.