On Saturday I attended the first SpeaKonf in Darmstadt, an unconference specifically for conference speakers and those who want to become one. I’ve given a few talks already, such as “To SDK or not do SDK?” at APItheDocs or “Specification-driven APIs vs. Technical Writers” at tcworld, but I’m always eager to learn and improve.

The unconference was a one-day event organized by the Java User Group Darmstadt and supported by cosee, who opened their offices for approximately 40 participants. After a typical BarCamp-style planning session, we filled three tracks with 15 session proposals. Here’s a quick summary of the sessions in which I participated.

The first was about using images in slides. Pictures, especially photos, can support a talk’s message on an emotional level, but they must fit and not feel forced. To be safe in terms of legal compliance, always mention your sources, ideally as a small footnote on the slides itself, and store some proof (i.e., screenshot) of the licensing agreement, in case the source disappears or changes.

The second session was the organizer’s offer to have yourself recorded and analyzed, which I gratefully accepted, though being the only brave person to do so in a group with only three people. But the feedback from the other two was helpful.

After a catered pizza lunch there was a session called “Tag Teach”. It was led by Mirjam, who was a dog trainer before she became a software developer. She explained how conditioning methods, especially positive reinforcement, applied for teaching animals could also be helpful for humans to improve their behavior, for example, their posture or way of speaking in front of an audience. We did a few practical exercises, too.

The fourth session was about self-recording your talks, either for practice or if you want to keep presentations from meetups who don’t record them, so you have reference material when submitting to CFPs.

Finally, the last session was about live coding. We talked about the advantages and risks of live coding during a presentation compared to recorded screencasts and collected some advice for optimizing an on-stage coding session, for example using automation, IDE shortcuts or storing various states of your project so you can quickly access them if necessary.

The day ended with a retrospective. There was a lot of positive feedback, but many including me thought that the diversity of attendees should be improved. Java developers and conference veterans were overrepresented whereas there was a lack of novices and people with a non-technical background and perspective.

But altogether, the trip was worth it, also because of the “hallway track” in which I got to know Ralf who runs docs-as-co.de, a website that advertises a docs-as-code workflow based on AsciiDoc. Talking to him inspired me to dive even deeper into optimizing and automating API documentation.