Reading Time: 15 minutes

It’s con season in the tech world. Yesterday evening I flew from Pluralsight‘s Link/ unconference in New Orleans to Pycon US in Salt Lake City.

New Orleanians are just as likely as not to offer you a drink within sixty seconds of greeting you. Eighteen hours after leaving there, I walked into the Salt Palace Convention Center and made a joke about still needing my caffeine to almost-certainly-a-mormon.

I spend a non-negligible portion of my time at tech conferences. I have thought a lot about the purpose of that time.

Are tech cons special?

In 2020, Hillel Wayne started a crossover project on the subject of whether software engineers are really engineers.

The final piece in his writeup addresses things that traditional engineers could learn from software engineers: version control, and our cons. That’s right:

We software engineers take the existence of nonacademic, noncorporate conferences for granted. But we’re unique here. In most fields of engineering, there are only two kinds of conferences: academic conferences and vendor trade shows. There’s nothing like Deconstruct or Pycon or !!con, a practitioner-oriented conference run solely for the joy of the craft.

– Hillel Wayne, ‘What Engineering Can Teach (And Learn From) Us’

Though cons like ours might not exist in other areas of engineering, we see a similar phenomenon within other communities. Nerd fan communities have their cons, like C2E2 and WorldCon. Film buffs have Sundance. People who show model horses (yes; small plastic horses) have Breyerfest. Programming, for whatever reason, has adopted the con structure of a globally distributed fan club rather than a profession.

Practitioner-led, joy-infused fan club conventions tend to pop up around some sort of cash cow. Folks go to C2E2 to get the cast of their favorite show to sign their memorabilia, and they’ll pay for the privilege. Breyerfest and Sundance attract big players to judge and compete, and winning accolades at those events means something for community opportunities later.

Tech conferences have their high profile keynote speakers and sponsor tables, but they don’t seem to need a cash cow to exist. Attendees don’t go, and speakers don’t speak, with the specific goal of buying and selling wares. Tech is lucrative. Companies will sponsor in hopes of recruiting a candidate or two; making a hire costs a median $70k in tech, so even a couple of bites at a conference are worth a $5k sponsorship fee. Software engineers also tend to receive relatively unregulated professional development budgets from their employers, which they can use to come to the cons without too much persuasion. These structures create slack that allow tech cons to focus less on the finances and more on idealistic goals. And like all idealistic sixties children, the tech industry loves itself a sentimental narrative.

What’s that narrative? A lot of conference kickoff speeches will say something along the lines of “have fun and make friends” or “enrich the community,” or they’ll quote that Muppets song where Gonzo quotes Jim Henson.

These cons get to eschew the gatekeeping associated with slating an academic conference. People aren’t required to have an advanced degree or discuss a published paper to speak at a tech con. Folks can share their perspective without having a thing to sell and without having a paper that they need cited.

Perhaps the looseness of the money in our industry never forced the cons to articulate a value proposition, or perhaps engineers hate selling. Either way, we’ve never clearly stated what we’re doing at these cons. I’m happy to take a stab, but first I want to address misconceptions that lead to the inaccurate expectations and dashed hopes wafting off of cons.

Cons are not masterclass summits.

I have a friend who founded a school specifically for teaching shibari—a skill with its own lively schedule of fan cons. That friend doesn’t think it’s worth the time or money to attend a con. The people who get the go-ahead to speak do not always meet this person’s practitioner standard, and their teaching skills often leave something to be desired. Between travel, hotel fees, and the ticket, you’re spending hundreds of dollars, minimum. If you spend that for the purpose of attending four or five seminars, only one of which might end up being useful, it starts to look like a pretty bad deal.

I’ve said myself that “I get very little out of 95% of tech talks.” Just this morning I walked into a packed lecture hall, discovered that the presenter’s slides for this 100-person room featured 16 lines of code in 8-point font, and walked back out. Tech talks, by and large, don’t teach topics. They’re nowhere near good enough for that. They might make you aware of topics, and that can be worth something. That’s harder to measure, though.

Cons are also not industry newsletters.

I have a professional acquaintance who recently pitched a fit on Twitter over RailsConf not accepting his talk this year. This person works on a tool that much of the Ruby community uses, and he had submitted the talk “What’s new in <the tool>,” and it had not gotten in. In most previous years, I think he did get in with this talk. So he took to Twitter to accuse the organizing committee of caprice.

Now, I’m not on the RailsConf committee this year, but I have been on it in the past. I was on it the year that RailsConf decided not to make DHH, who wrote the original version of Rails, the keynote speaker. DHH responded to that decision with a blog post that sent his supporters scurrying to critique (fine), cuss out (not fine), and threaten (wtf guys) the organizers. To organize a tech conference is to volunteer countless hours of your time and be harassed via email and social media by self-righteous, entitled jerks.

Anyway, if you’re looking to go to a singular event and get all the updates on the big players for that year, you’re making a mistake. I actually don’t think conference attendees often make this mistake. I think self-important library maintainers decide that cons are about them, and then they get upset when faced with evidence that they are not—at least not in their capacity as figures of power.

Cons are not kingmakers.

They’re not about our celebrities; they’re not about our tools. Conference organizers don’t discuss what so-and-so wants to say this year, and then pick talks based on that.

Instead, talk selection usually belongs to a rotating group of volunteers. It’s anonymized, theoretically to minimize the temptation to engage in friend-nepotism. Reviewers know the title and the abstract, and maybe an outline. Most submitters don’t submit a very complete outline. There’s very little info to evaluate on. I am a professional educator, and lemme tell you something: the title and abstract of a talk tells you nothing about how good it will be¹.

How do reviewers make choices in this situation? A lot of times, they isolate a few themes. “This year, let’s focus on talks about these 4 things.” They pick enough topics to attract a broad cross-section of their target audience, but a small enough number to accomplish two goals:

1. Have enough talks within each topic that, by the law of large numbers, one of ’em at least (and hopefully a few) will be decent.
2. Maximize the chances that folks talking about these things will derive value from meeting each other in real life.

Objective #2 focuses on optimizing the hallway track: the unscripted, unplanned conversations that take place “in the hallway” outside the talks.

Con attendees love the hallway track so much that they’ve gone beyond “pick the right presentations” and developed a whole event category—the unconference—around picking no presentations. Unconferences instead feature hackathons, pair programming speed-dating, lightning talks, improv games, or attendee-driven schedules made with post-it notes on pieces of cardboard. The activities explicitly encourage extemporaneous conversation.

Conferences tend to select presentations via an anonymized process and than make attendee tickets available for public purchase. Unconferences, by contrast, tend to forego a ticket fee and hand-select attendees. You don’t register for an unconference; you get tapped. How you get tapped varies from unconference to unconference. In some cases, organizers invite colleagues or folks they admire from the internet. Sometimes they ask folks they trust to recommend voices (often newer, marginalized voices) for an invitation. Sometimes they collect referrals from past attendees.

The conference and the unconference sound like opposites. But they implement differently for the same objective: concentrate the right groups of people into a space to catalyze conversations that lead to Big Things.

Cons are conversation catalysts.

When organizers talk about the point of conferences in private, they use phrases like “bring people together” and “make friends” and “ugh…networking” and other vague platitudes that, admittedly, don’t do a great job of communicating the value we’re trying to create here.

And this intractable value, so difficult to articulate, perhaps impossible to measure, unfortunately carries the utility of the tech con.

Note: utility is different from attractiveness. Utility is “why it makes any sense to create this thing, and what attendees get out of it.” Attractiveness is “why do people come.” Conversation catalysis doesn’t carry the attractiveness of a tech con. Why do people come? I mean—to travel to a new city on the company dime, of course! Plus, if you can take a few days off work without having to burn PTO days because it’s a conference, why wouldn’t you? I make over a quarter of my income teaching tech skills online. This has demonstrable utility for developers: they can take a workshop on the exact skill they need for their day job. But while developers show up in droves when the company prepays, they don’t want to spend their own professional development budget on trainings. They wanna use that money to travel, and cons launder travel into a work expense. Programmers will say they’re going to cons to network, but remember: we’re talking about programmers here, the exact same people who we quoted earlier in this very post as saying things like “ugh…networking.”

The relationship between cons and prodev sounds underhanded and self-serving, but I think it’s fine. First of all, I think it’s pretty hard for individual employees to out-use the companies that employ/use them. But maybe more importantly, the con still ends up being worth it for the employers, sponsors, organizers, and attendees through this difficult to articulate, perhaps impossible to measure “conversation catalyst” thing.

Avdi Grimm talks about “obliquity.”

He’s a developer and teacher in the Ruby community, and I first met him at dCamp in 2014. I had been invited to that unconference on the recommendation of Coraline Ehmke to its organizer, Evan Light. At the time I had relatively little programming experience. To me, Avdi felt like a celebrity: the skill, the cachet, the rockstar hair. We did not become fast friends, but we did chitchat next to a camp fire and slowly build a friendship from there. Nowadays, I voice message Avdi on Whatsapp about dating (Avdi and I are not dating each other; I’m a lesbian and he’s out of my league anyway) or when I have a reaction to Tech Drama that’s too spicy to say in public. Anything salty you see on this blog, Avdi heard it weeks ago.

Who gets credit for that relationship? Is it the two of us? Is it Coraline? Is it Evan? Is it whoever sponsored that instance of dCamp? Would credit have gone to the employers who compensated us with the prodev budget that put us on airplanes to that event?

And who benefits from that relationship? Obviously me and hopefully Avdi, but also, anyone who reads one of my spicy blog posts that sounds better because I talked to Avdi first. Anyone who has watched me talk about risk-oriented testing on Avdi’s RubyTapas. Anyone who has heard me speak at DDD Europe or SkillsMatter—cons that I only applied to because Jess Kerr, who I met through Avdi, recommended them. And for that matter, my employer benefits because when I speak at those cons I get up and say “Hi, I’m Chelsea; I’m an engineer at Mozilla.” And after I give my killer talk, folks come up and ask me what I do at Mozilla. And when I tell them, they want to work at Mozilla. And if they do come work at Mozilla, I get a sweet little referral bonus. But even when you subtract my referral bonus, Mozilla saves about fourteen thousand dollars on recruiting outreach. That’s close to five times my annual prodev budget, saved over a con.

Eventually someone cashes in on cons, but the mechanism is a Rube Goldberg machine. We back into things without really aiming for them. That’s what Avdi calls “obliquity,” and he posits that relationship-based successes are best reached obliquely as opposed to aiming directly at them. I don’t mean specifically romances here; any relationship.

Cons become worth it from the conversations that happen between folks who otherwise might not have met, that endure beyond the event itself. Most of the time, those conversations amount to relatively little: a cool fact, a fun sidebar, a mutual Twitter follow. Sometimes they amount to more: a piece of advice that non-negligibly improves someone’s work project. Occasionally, people refer each other for jobs or kick off meaningful collaborations. And although cons ask us to pour balls into a Rube Goldberg machine with no guarantee about where they’ll pop back out, I have a suspicion that over time balls pop out roughly proportionate to who’s pouring them in. Those balls have a large aggregate margin: though it might only happen once in five conferences, one referral still nets my employer a return on my annual prodev five times over, and any value created from the other four conferences is slush on top of that. So there are plenty of balls to spare for other community enrichment efforts to get some balls, too.

It’s infuriatingly random and untrackable and disorganized. It offends our sensibilities about data and determinism. The most incensing part? Empirically, it works.

Cons owe you nothing.

It turns out that I (and you) have almost certainly benefited from cons we’ve never been to and never heard of. Someone has helped us in some way because they met someone else at one of those cons. You can insist that the formal education offerings are not good at cons (and you’re mostly right). You can be pissed off that your talk didn’t get into a specific con (entitled, but sure). You can wonder why so-and-so isn’t coming, and so-and-so is coming, and who made that decision. You can even say “you know what, this is not for me” and abdicate going to cons altogether. And still, cons would impact your experience in tech because they contribute to the richness of tech itself in ways you’ll never be able to itemize.

Footnotes

1. There are a few engineered exceptions to the “title tells you nothing” rule. For example, in the Ruby community, there’s a guy who has made a name for himself giving talks that feature lemurs. If the proposed talk title has lemurs in it, it’s this guy. This actually creates a problem for the CFP committee because you’re supposed to abdicate if you know who the submitter was, and in this case we all know who submitted it. The guy is objectively more skilled at speaking than 98% of the field, so transparently we do want him to speak, but we have to decide if it’s OK for us to accept because we know it’s him, despite the fact that we call our CFP anonymous. I have so far seen the lemur thing hang up two CFP committees.

Oh, you liked this post?

If you want to be the one developer in twenty who actually gives a useful con talk, I wrote about how I do it, and you can judge my fitness to speak on that by watching some talks I’ve given.

Or, if you need a change of topic, you can watch me yak about spotting misinformation in articles discussing what “studies have shown.”