TCCamp 2016

Two weekends ago, I attended the fourth TCCamp (the third I’ve been to). As always, it’s a great chance to meet with fellow tech writers at an informal “unconference” that relies on the attendees to choose the discussion topics.

I volunteered this year, and I’ll admit that I was having second thoughts about that. Not only because I had to wake up early to be there before the morning sessions started (although I’m never very fond of waking up very early on Saturdays), but also because I was worried that I would miss most of the conference. Fortunately, I was wrong. It was a great experience, and I don’t think I missed anything.

So, let me tell you about moving tables around…

Ha. No. But yes, I did move some tables. I also missed the morning sessions. There was one about using Github that I regret missing, but to be perfectly honest I’ve learned enough introductory material about Git. Another class, no matter how good, won’t change the fact that I need to dive in and get beyond the “I know the basic commands” stage. Honestly, I’m still far too excited when I can edit a file and check it in without errors.

The interesting parts of the confer…sorry, unconference that I did get to participate in were the afternoon roundtable sessions. From a list of 70-odd topics, the attendees vote and the top 24 topics become the schedule. There are six discussion locations (groups of tables), with four rounds of afternoon discussions. Most of them are problem statements: how do I get people to review the documentation; how do you handle a Word-to-DITA workflow; how do you work with illustrations? And then, instead of listening to one person describe how they solved that problem, everyone talks about the problems. Maybe what they’ve encountered, ways they’ve solved the problem, or ways they might want to solve it. Someone volunteers to take notes, and someone volunteers to lead the discussion (kick it off and keep it moving). This idea works really well: tech writers love to think about problems and solutions, and all of the discussions I was in were very active. We were able to have a good discussion in 45 minutes, and I’m sure that most of them could have gone on longer.

Even in the cases where we couldn’t find a clear solution (most of them, to be honest), the point was to get people thinking by talking about the problem and learning how other tech writers approached it. No one is going to find that one perfect trick to get reviewers to return insightful comments before the deadline in a 45-minute discussion. But with lots of “I’ve tried this” and “maybe we could” suggestions going around, it gives us some new ideas.

I love being a lone tech writer because I get to decide what tools to use, what my review process will be, and how I’ll publish the documentation. But then I have no help to push through the impossible number of options and I have to navigate the large number of opportunities to crash and burn. And there’s no one sitting next to me who I can bounce ideas off of, or who will point out questionable assumptions and get me thinking in new ways.

One session was “Writing best practices.” I (and a few others) thought this would be a discussion about how to write best practice topics. But most of the other people thought it was about best practices for writing. I wasn’t very interested in that topic (been there, done that, written more than one style guide), but I perked up when people started talking about building templates. I love templates, and I use them to help other people who want to contribute to the docs but don’t know where to start. But building a good template isn’t easy, and it was great to hear ideas from others writers about what has worked for them.

One more thing I learned: there aren’t as many tech writers working in an Agile/Scrum environment than I had assumed. I’ve been working with Scrum teams for the past 10 years, so I figured that a lot of other writers would have a similar experience.

I was surprised, but this is also good news for me, in a way. I’ll be speaking about working as a technical writer in an Agile environment at the WritersUA conference in April. I had wondered whether this would be new to anyone, and I have to admit that I’m a little relieved that is still an unknown area for some people. I still feel a little awkward because I’m certainly not a “thought leader.” I don’t spend as much time with the theoretical notions that underlie our industry; I just pick a direction that looks good and then I plow forward. Then I pop my head up, get my bearings and change course if I need to, and keep going.

Which, now that I write it down, is probably why I really like Agile.