Live-Tweeting for Fame and Fortune

That’s a joke. I have made $65 off 4 years of live-tweeting, and it’s more than I ever expected. As far as fame, the point is not for me to get famous, but to promote some amazing speakers as they do their thing.

I don’t know about you, but I have about 20 tabs open in my browser with technical talks that I’m excited about seeing and will get around to anytime now. As soon as I have 45 minutes that I’m not doing something else. Don’t @ me.

It is hard to make space in our lives to consume technical talks. It is much easier to consume a tweetstream that summarizes the key points of the talk.

So what is it that makes live-tweeting successful, and what are some things to avoid?

Tools

Hardware

I use an iPad as my main conference-going computer. It’s powerful enough to write on, remarkably unfussy about connecting to a conference wifi, and small and cheap enough that losing it will not be catastrophic. I also present from my iPad, but that’s a different story.

I’ve paired that with a bluetooth keyboard that I bought with some of my donations. I like the combination because I can set it in my lap or use in in a number of weird orientations. I’m a pretty fast touch-typist, so I can take notes quickly enough that I can capture most main points.

I have a wifi hotspot that I keep in my go bag. I’ve had very few problems at conferences in the last year or two, but before that, there was a pretty good chance that a technology conference would overwhelm whatever wifi infrastructure the venue had set up.

My final hardware investment is an iPad case that allows me to prop it in several different configurations, including horizontal and vertical. I always choose the ones in screaming pink/fuschia/etc, because I’m pretty sure that “girly” looking technology is less likely to be “accidentally” picked up by someone else. Also, it’s very on-brand!

That’s me, in the pink hair, live-tweeting from The Lead Developer New York 2017. You can see the keyboard and iPad balanced in my lap. (It’s a great conference!)

Software

I am an enormous fan of NoterLive by Kevin Marks. I met him at Nodevember in 2016, I think, and he has created an amazing tool for live-tweeting.

  • Prepends the conference hashtag(s) and speaker name for every tweet, so you don’t have to retype them every time (although if you get it wrong, it will be a lot wrong)
  • Automatically threads until you tell it to stop
  • Local caching and logging

Pretty much all I have to do is set the conference hashtag by the day, start a new thread, set the speaker, and then I can type without worrying about it and the tweet is sent every time I hit enter.

It’s aware of character limits and will give you notice when you’re approaching it. The only thing that’s a tiny bit hinky, and I still don’t know if it’s happening, is that it will sometimes attempt to make a link if I have some combination of a period and spaces. It doesn’t send the link, but it throws the character count off.

💖

I use TweetBot on my iPad to watch the conference hashtag and retweet things that are cool and relevant that I didn’t get noted or didn’t see. The new TweetBot for Mac just came out, and they finally have a dark theme and a much better way of handling and viewing lists.

I used Storify to compile all the tweets about my talks and weave a loose story about the experience, but it’s gone and I am very sad and I’ve not yet found a replacement.

Techniques

For Speakers

  • Put your handle on every. single. slide. No, I am not kidding. I want to be able to attribute your stuff properly, and if I slide in 2 minutes late and miss your first slide, then I have to spend 3 minutes hacking around the conference site to find it.
  • Put the conference you’re at in your Twitter display name. That allows people to mute if they want, and it makes you easier to find and correctly identify.
  • If you don’t use Twitter, give us some other way to attribute you, because attribution matters.
  • Follow the code of conduct. A live-tweeter in your talk is a great force for good, until you piss them off, and then they’re going to take pictures of your offensive slides and drag you.
  • Turn off all notifications before you get on stage. It’s super distracting to have your phone freaking out at you while you’re trying to speak and even worse if it’s your laptop.

For Tweeters

This is actually just the set of rules I try to follow for myself. There isn’t really a journalistic code of ethics for tweeting.

  • Attribute ideas properly. If a speaker is quoting someone else, do your best to make that clear.
  • If you are making an aside, try to set it off in some way. I use (parentheses), and @lizthegrey uses [ed: ], but as long as it’s clear you’re commenting on the content and not reporting, anything works.
  • You do not have to exactly quote what someone says. Paraphrasing is the norm. If there’s some especially unique phrase and you have space to get it in, you can put quotes around it, otherwise you can just do your best to approximate the concepts.
  • If you’re taking a picture to go with a tweet, it doesn’t have to be perfect, but do avoid making the speaker look unreasonably dippy. It turns out it’s hard to speak without sometimes making extremely weird faces.
  • Use hashtags and threads to make it possible for your regular followers to block the tweetstorm out. Not everyone is here to read 200 conference tweets.
  • Put the conference you’re at in your Twitter display name. That allows people to mute if they want, and it makes you easier to find and correctly identify.

Let’s Not

There are some anti-patterns that I’d like you to try to avoid:

  • Just transcribing the slides for a talk
  • Commenting on anything about the speaker’s appearance
  • Negativity in general, really. I mean, why waste your precious conference time and dollars hate-watching a talk and tweeting about it? Get up and go do something else. You’re allowed.
  • Violating a speaker’s publicity preferences. If they have a “No Photos” lanyard, don’t take photos.

Add To Your Lists

@lizhenry – the OG livetweeter, the one I learned so much from. Good for Mozilla information, politics, and feminist poetry.

@cczona – the mind behind Consequences of an Insightful Algorithm AND @Callbackwomen. Excellent at pointing out connections between different threads of technical talks and the implications of them.

@lizthegrey – Google SRE, badass speaker in her own right, and excellent at documenting and commenting on lots of topics, especially resiliency.

@EmilyGorcenski – livetweeting not just technical conferences, but resistance politics.

@CateHstn – Thoughtful blogger and live-tweeter operating at the intersection of dev and management.

@bridgetkromhout – indefatigable DevOps organizer and excellent live-tweeter. She actually manages to take pictures and livetweets from her phone. I’m in awe, honestly.

@whereistanya – a systems thinker who managers to pull tweets and blog posts together and make you see a side of the talk that you might not have recognized.

@GeekManager – conference organizer and integrative thinking on the bleeding edge of the humane treatment of developers who end up managing.

@QuinnyPig – Not always a perfectly accurate rendition, but always funny (and clear) about the divergence

@MattStratton – brings an insider perspective to talks, which allows him to point out connections you may not have thought of.

@skimbrel – technical expertise from an unapologetically queer viewpoint. It’s not paranoia if they’re really out to get you.

Using Airtable to Manage Conference Submissions

I know, it’s not a very catchy title, but it is descriptive.

A large part of my current job is speaking at conferences and talking about feature flags, systems resiliency, and whatever else I can talk people into. And part of speaking at conferences is applying to lots and lots of conferences. But how do you keep track of it all?

At first I tried to use Google Calendar, but that did’t work. I tried Trello, but there weren’t enough dimensions. I wanted to track these elements:

  • Name
  • Location
  • Start date
  • End date
  • Talks submitted
  • Submitted/accepted/rejected/conflict
  • Speaker tasks
  • Tasks remaining

That’s a lot! I complained about the problem, and Thursday Bram suggested Airtable, as a beautiful mashup of a taskboard and a spreadsheet. Since then, I’ve suggested it to several other developer relations people and I know some of them are using it. I’m now paying for the full version, which gives me the calendar view, and that’s been my killer feature. It really helps me to be realistic about how conferences stack and overlap with each other.

Spreadsheet

Airtable main view

This is the main view. I have it sorted so that conferences that are over or that have not accepted any talks from me are not showing, because I really only need to know about what is coming or may be coming. I’ve grouped it by the Talk Accepted dimension and then the date. At a glance, I can tell what I have coming, and what talk I’m giving (if I remembered to enter it, because I’m sometimes not great at that, as you can see.

Cards

I can drill down into any talk title for a card that has a bunch of information on the talk. Frequently I include the proposal I submitted here, along with information about how far along in the process of creation the talk is, all configured by me. Have I drafted it? Made slides? Practiced it on my own or in front of other people?

Cards Pt. 2

Further down on the talk card, I can see all the conferences I submitted the talk to and whether it was accepted or not. That gives me a good overview of whether a talk is “wearing out” or less likely to be accepted than another kind of talk. It’s useful information.

All of those features are available at the free level, and it’s powerful enough for most people, but did I mention I apply to a lot of conferences? More than there are weeks. You probably don’t need the full version.

Calendar View

Airtable calendar view

This view right here is worth everything I spend on Airtable, and I’m certainly not a power user. But it tells me about conflicts in a way that has been very hard for me to predict from just looking at dates. (If we were all good at predicting conflicts from dates and times, we would not have Outlook Meetings Calendar, is what I’m saying) Now I can tell ahead of time that I can only accept one of those three conferences starting on the 24th, and that allows me to be a more polite speaker. Sometimes it’s possible to look at this and make better arrangements. For example, DevOpsDays Chicago is a great event, but it’s literally the day before I need to be in Dusseldorf. Rather than discombobulating myself or the conferences, I can ask now, months ahead of time, to speak on the first day of DevOpsDays Chicago and toward the end of SRECon. That gives me an error budget for weather/flights/etc. Most conference organizers are lovely about helping me out with these things.

Conclusion

Airtable is a super useful tool for being able to organize data when some parts of it are fixed and some parts change and you need to be able to keep the associations together. There are bigger, more heavyweight databases that can do that, of course, but this is a pretty, friendly, usable implementation of the theory.

If you’re interested in trying it yourself, here is a link to the original workspace I set up: Heidi’s Conferences. Feel free to give it a spin or fork it for your own needs.

A small succulent plant with the San Francisco skyline in the background

Crosspost: The Recompiler Magazine, Issue 8: Build Your Interviewing Strategy

I’m a huge fan of The Recompiler, and not just because they sometimes publish my work. I support anyone who spends the time and effort to publish articles that are useful, thoughtful, and frequently action-oriented.

Carol Smith (of OSI board fame) and I put together a workshop for people who are doing technical interviews for the first time. We called it “The Hardest Part of Tech(nical Interviewing) Is People”. We’ve given it a couple times, and we’re hoping to do a recorded version. This article is part of what we talk about in the workshop – how to look over your past experiences, even if they weren’t in technology, and make them relevant and applicable. We hope this helps you!

Build Your Interviewing Strategy

And in conclusion, support your local publications!

The Recompiler Magazine

Documentation for DevOps: A DevOpsDays Open Space Writeup

I’m borrowing this image from my friends at Chef, because it’s really funny to pretend that it’s possible to just sprinkle on “devops”, something that is about cultural change at every level.

At every DevOpsDays I go to (and that’s quite a few), I propose/wrangle/run two open spaces. One is about feature flags/canary launches/hypothesis-driven development, and the other is this one, which I usually refer to as “Docs for DevOps”.

DevOps documentation is difficult because it’s not intended for external audiences, so it’s hard to make a case for hiring a writer, but it’s also mission-critical, which means that it can’t be ignored or neglected.

I also have a talk that I give on this topic. You can find recordings from DevOpsDays Minneapolis and NDC Minnesota here. but this is specifically about the open space. I am indebted to a number of people in the last year who have come to open spaces, shared their experiences, asked questions, and challenged my thinking and assumptions.

I’ve grouped the questions I hear most often into these categories:

  • How can I find anything?
  • How do I get people to read the docs?
  • How do I get people to write the docs?
  • My team is small, do you have particular advice?
  • My team is very large, what should we do?
  • Distributed team best practices?
  • Why is sharepoint?
  • What tools are most useful?

How can I find anything?

Frequently, the first problem that people have is not that nothing is written down, but that lots of things are, and the problem is discoverability and accuracy. It’s one thing to have instructions, and quite another to have instructions that you can find when you need them. Many people have their operations documents spread across one or many wikis, ticketing systems, and document storage platforms.

The short answer to this problem is “search”. That is also most of the long answer. The thing I think we overlook is that we don’t have to use the search engine that came with our wiki. We could put something else in front of it. With the demise of the physical Google Search Appliance, you still have a number of service options. Most of them will give you the option to index and search multiple sites.

As a consultant who helped companies structure documentation so it was usable, I have a lot of specific advice on how to change the architecture and the culture, but honestly, if you could get your company to hire someone to help with that, you could probably get them to hire a writer and solve the problem another way.

The last part of this answer is that you could get some consulting dollars and hire an archivist/librarian to help you come up with tags that help identify the types of data and make it easier to search for. When we’re trying to recall data, we frequently do so by keyword or tag, and an archivist can help you make a canonical list of what people should use for that.

How do I get people to read what we have?

First, see above, make it easy to find.

Second, make it as easy as possible to read. Sit down in a group and hash out what type of information has to be included to make a topic/article/page useful to others. Once you know what you need to have included, you can make a template so that people remember to include it all.

The next problem is to figure out how to point people to the documentation without being dismissive or making them feel like you are too good to answer their questions. This might be a good place for a chatbot, or a single web page full of resources.

Many people would rather be able to find an answer themselves than bug a coworker to get it, so if they’re not reading the documentation, there’s probably a systemic problem blocking them.

How do you get people to write the docs?

Do you know any sysadmin or SRE who has ever been fired for lack of documentation?

Do you know of anyone who has gotten promoted solely on their ability to write internal documentation?

Most of us don’t. No matter how much organizations say they care about documentation, they are not putting anything of meaning behind those words. It’s not malicious, but it does tell you that documentation is not actually something they care about.

One of the ways to fix this is by using a reward system. Buy a package of Starbucks cards, or awesome stickers, or ice cream certificates, and give them out every time someone completes a documentation task, immediately. Adding a tally mark for their eventual review is much less motivational than immediate rewards for work. You don’t have to be a manager to do this – anyone can motivate their co-workers. The reward doesn’t have to have cash value, but I do think it’s the easiest way to indicate your appreciation.

Another thing to pay attention to is how easy or hard it is to write the documentation. If it’s a complicated system, the barrier to entry is high. If it’s in a tool the team already uses, in a language they already know, it’s much easier to persuade them to drop in a few lines. if there is a form for them to fill in so they don’t have to figure out what they are supposed to include, that’s even better. Lowering the cognitive barrier to entry is as important as the tool barrier to entry. After all, we’d have a lot more trouble writing bug reports if we had to write them out by longhand without any fields to fill in. Documentation is the same way.

My team is small

Consider using just one single page of truth. No, seriously. If you’re working with a team under 8, and especially if they’re distributed, consider just putting everything on one single web page and searching it when you need to find something. The overhead of managing a documentation system or wiki is not something you need when your team is that small. As you write new things, they go at the top and older stuff gets pushed down to the bottom and becomes obviously less important or relevant. If you need to find something, you can easily search the page. No one has a secret pile of documents that the rest of the team doesn’t know about. It’s not an elegant solution, but it’s hella utilitarian.

My team is large

Hire a writer. And/or a librarian. I was talking to someone whose IT organization was over seven thousand people. They obviously do need some structure, some tooling, some information architecture. Rather than spend internal IT cycles on it, I suggest hiring experts. There are thousands of people in this world who are trained to manage, collate, write, and wrangle large sets of documents, and it’s wasteful to try to do it by yourself.

What are the best practices for distributed teams?

Pretty much the only effective way to have a distributed team is to change the team culture to one where you write down questions and answers, instead of popping by to share them. It’s important to make sure that key data is always written down and not passed on by word of mouth, because as soon as you have an oral culture, you are leaving remote members out.

It’s useful to have at least one team member working remotely who has distributed team experience. You can ask them for what has worked for them in the past and enlist their help in iterating your practices. For example, is it hard for the team to remember to set up the call-in for meetings? Change the meeting template to include a shared meeting room automatically. No one gets a distributed team right immediately, anymore than we do a colocated team. It’s just that it’s easier for distributed teams to end up in a broken state before someone notices.

Why is SharePoint?

Because the paradigm and core analogy is filing cabinets. “What if I could see inside the Operations filing cabinet?” Because it thinks of itself as a way to organize pieces of paper, it’s not very good at documents that need to be shared and altered simultaneously across organizational boundaries. It was a marvel for its time, a way for non-technical users to get their documents out of shared drives and file cabinets and give other people regulated access, but it is fundamentally hostile to searching.

What tools are most useful?

It depends, right? Tools exist on a sliding scale between absolutely zero barrier to entry on one end and and taxanomic usefulness on the other. Every team must find their own best place, which may not be the same across the company. But if a team dislikes a tool or finds it burdensome, they just won’t use it.

The best tool is the one you can get people to adopt. If your team is 100% people who know how to use LateX and created their resumes and gaming character sheets in it, then it would be a fine tool. If you had a team composed entirely of people under 20, maybe a a youtube channel would be the way to go. Since none of us have completely uniform teams, the best thing we can do is to find a tool that everyone can grudgingly agree only sucks a little bit.

In conclusion

  • Use a better search engine
  • Hire experts whenever possible
  • Make it easier to write things by using templates
  • Iterate and keep improving your devops docs process. There’s no solution, just a fix for now.