Previously
What I’ve been up to
I’ve done very little writing lately. If it weren’t for my guest appearances on other shows, I’d be doing zero podcasting. I’ve been traveling frequently for work and a whole bunch of conferences while effortfully maintaining new food and exercise habits. That’s all I’ve had time for.
After this week’s Path to Agility conference, I’ll be traveling less and working from home more. I expect to be writing regularly again, starting now. Since I’ve been speaking regularly, I’ve been incrementally improving how I present and publish. And since I’m about to take a break from conferences, here’s what I’ve figured out so far.
Notice CFPs of interest
”CFP” == Call For Proposals. Or sometimes Papers, but I haven’t written any of those, and am intimidated by the title.
I mainly become aware of conferences when someone I follow on Twitter mentions them, or sometimes when someone I meet in person recommends them. Last year I assembled a list of “2015 conferences I may want to attend”. I found it so useful that I did it again this year. Suggestions and corrections welcome!
Recently I became aware of the Technically Speaking and The Weekly CFP newsletters (probably via Twitter) and subscribed.
It’s also possible to bypass the usual talk submission process by receiving a personal invitation to speak. I’ve been invited a few times. When this happens, it’s very flattering, and it drives home the continued need for me to participate in the usual process. I’ve had lots of talks rejected. If I hadn’t kept at it, gotten some acceptances, and made the most of them, the folks who’ve invited me to speak to their audiences wouldn’t have known I had anything to offer.
Moral of the story: keep submitting, keep presenting, keep practicing.
Write an abstract
I have not, by any stretch, mastered the art of writing a winning abstract. I do know what I like as an attendee. What draws me in? Among other things, I look for a story from personal experience. That helps me understand how being there might change my own story.
We discussed this on Agile for Humans 032.
Save a copy
If an abstract is accepted, I might want to submit it to more conferences. If an abstract is rejected, I might want to tweak it and submit it to more conferences. Either way, I don’t want to rely on being able to pull a copy out of a submission system. I do my writing in my personal wiki (an ikiwiki instance, naturally), then submit a copy.
Rejected? Try again from the top
Program committees and organizers don’t usually have time and energy to give personalized feedback. If my talk was rejected, it’s up to me to figure out what that might mean and what I might want to do about it. I might try to find someone who gives talks and get their personalized feedback. Or maybe it was one of the many perfectly good talks that get rejected all the time, and submitting verbatim to another conference is worth a shot.
Accepted? Publicize
I write a very short page linking to the conference, my session, and where to buy tickets (if they’re still available), and I tag the page talk-pending. That automatically adds it to the list of upcoming appearances on my speaker page, and also (via rss2email) turns it into an email message, which gets sent to my low-volume mailing list.
Sooner or later I’ll mention the talk on Twitter, etc., as well.
[Talk planning goes here]
I have no profound thoughts about how to put together a winning talk. Have experiences, figure out what’s interesting about them, extract the story arc.
Write slides
I’m not, as yet, attempting to design fast-paced, visually arresting slides. I’ve been trying to keep it simple for myself instead. After several iterations, I’ve landed on a comfortable setup for writing and publishing decent web-based slides.
I used to use S5. No special tools: write HTML, get slides. I was happy with it. Here’s a deck from a lightning talk a few years ago.
Last year, after migrating this site to ikiwiki, I was finally able to write new posts in Markdown. I wanted to be able to write slides in Markdown too. Remark.js does that. The easiest way to get started was to use it exactly as directed, then let ikiwiki’s rawhtml plugin preserve it for publishing.
The third time I published Remark.js slides, I noticed it was my third local copy of an old version of Remark.js. So I put it in a central place, adjusted the three references, and upgraded to the latest version — with git commits at each step, just in case I broke something. (I love having my site in git.)
This reduced duplication would certainly simplify my next slide-writing experience. To simplify it further, I wanted to extract the shared HTML and CSS. So I wrote a plugin for ikiwiki that provides the standard Remark.js template and styles, along with ikiwiki-idiomatic ways of overriding the template and styles.
Now I write my_slides.remark just like I’d write my_blog_post.md.
I locally preview the same way, too: commit, triggering an incremental
render. Quick and easy.
Finished? Publish
When the talk’s over, I:
- Squash unneeded intermediate commits
- Write a very short post linking to the abstract, slides, and any other related information
- Replace the very short publicity page with a redirect to the new post
git push
This used to be a less streamlined process. Now I do it immediately after the talk.
Further improvements
It’s a very common ikiwiki configuration to allow anyone to web-edit any page. That’s not a smart thing to allow for pages that are JavaScript-powered web slides. My site happens to be safe because I disallow web-editing, but if I want to stop carrying around a local copy of my code — and I do — then I need to make the plugin safe for inclusion in ikiwiki. That will require more thinking and doing.
At some point, it may become important to me to make fancier slides than Remark.js can produce. To do that, I’ll have to develop a new skill.