Our CFP has been open for a few weeks, and we've seen a lot of people searching for topics, sometimes asking us how to come up with one. It's hard to fire off an answer to a question like that. This is my attempt to capture some of the techniques that I use to come up with topics.

A brief note on my credentials. I've spoken at about fifty conferences. As I write this, my most popular full-length talk has been watched about half a million times. (Wat has been watched at least three million times, but it's a lightning talk so the process described here didn't apply.) I also organize a conference focused on talk quality. (You're on that conference's website right now.)

Most of my talks are centered on one or two surprising, or at least interesting, connections between ideas. For example, all of Boundaries is built up around only two of connections.

First: fully isolated testing has pitfalls when done with mocking. But small, purely functional components ("functional cores") give us much of the testability without those pitfalls.

Second: we can't build large systems out of fully functional components, at least in most popular languages. But we can arrange systems so that thin layers of impure code ("imperative shells") call the pure components ("functional cores"), but never vice-versa. This keeps the functional components self-contained and simple, making them easy to test and reason about.

That's a highly condensed description. Fully elaborating here would turn into Boundaries itself; it's better to just watch the talk if you're interested. In case it helps, here's how I'd say the same thing using terminology more native to the topic:

1. Small, non-interacting, purely functional call graphs are naturally testable in isolation without mocks.
2. Thin layers of impure code can join the larger pieces of pure code to build large impure systems.

Everything in Boundaries came from those two connections. Neither of them is surprising to someone familiar with the ideas, but I'd never seen anyone put them together and tell the whole story. I turned these two ideas into a few Keynote slides with just a few words each, then went to work expanding them into a talk.

(Talk preparation itself is a separate process that I'd like to write about some other time. It's significantly more complex than what we'll cover here.)

The problem is that insights like this can come at any time. Every time we solve a programming problem, the solution may be worthy of a talk. But we rarely record those insights for later user. So how do we record them, so they're available for review when there's a CFP to submit to?

I keep a long-lived Keynote file called _ideas.key to track talk ideas. It's an unorganized jumble of brief, cryptic notes to myself. (Because you're probably wondering: the underscore is there to make it sort first in the file list.)

People often want to submit a talk to a conference, but they don't know what to talk about. _ideas.key is my input: if I want to do a talk, but I'm not sure what it should be about, I can scroll through years of little notes to see what's interested me over time. A slide in _ideas.key could be anything – a snippet of code, a screenshot, a list of seemingly-related ideas, a joke; but all of them seemed interesting at some point.

The screenshot below is the first time that anyone has ever seen any part of this file. It shows one of the 50 slides currently in my _ideas.key. The slide's only job is to remind me of a thought that I already had, so it's very terse. Do you see the connection, or is it too cryptic? (I genuinely don't know; I'm too close to it!)

This slide relates a series of "left hand side" values to "right hand side" values. It suggests that in each case, the left hand side increases faster than linear as the right hand side increases. For example: if a diff is of length D, and our ability to understand it is U, then maybe U=kD² for some constant k, or maybe even U=k2^D, but definitely not U=kD. In more casual language: the longer a diff gets, the more confusion is added by each new line of it.

This is a wild guess. It's couched in excessively quantitative language; I'd never stand on stage and say "understandability goes like kD²." I did no research about this at all before writing it some time in 2015, and even as I write this I've spent no more than one minute thinking about it, ever. But it expresses the idea in a brief form that I trust future me to understand.

(Please don't steal this and do a talk called "Superlinear"!)

There's a problem with all of this. Deconstruct's CFP closes soon, so you don't have a year to accumulate an _ideas.key. But there's no rule that says you have to accumulate it passively.

Your homework is to create an empty _ideas.key right now. Then go through each of the categories below and make note slides about examples you can remember. One slide per idea or event. Use a big font. No formatting; just black text on white. Only add enough detail to remind you of the idea; don't write paragraphs. Here are the categories:

• Pairs or triples of tools/ideas/practices that people rarely use together, but have worked very well together for you.
• Problems that you recently got stuck on, but that seemed simple once you saw the solution.
  • Is there a way to prevent that from happening again?
  • Can you explain that solution to save other people the time?
• Differences of opinion about programming practices that you've recently observed or participated in.
  • Was it simply a case of people using the same word but meaning two things? (This happens a lot!)
  • Was it a case of people thinking about a tool or practice in different contexts, but not communicating their assumed context? (E.g., "X doesn't scale"... to 1,000 nodes, but our server infrastructure is currently 10 nodes.)
  • Can you pull out some topic from the disagreement, then talk about that topic without recounting an office argument on stage?
• Programming problems that resemble problems in other fields that you know about.
  • Second-career programmers often use this to great effect. But it does need to be an example that works for programmers without experience in the other field. Run it by a few programmer friends first, preferably ones who will give honest feedback.
• A surprising way that you've solved some problem, and it's worked at least three times, and you haven't seen other people talk about it.
  • The same thing but in reverse: a way that we keep failing at some task, but not noticing.
  • React and its virtual DOM are great examples of this kind of thinking. Bonus points because most people would've expected it to be impractically slow. Surprise!

You may not have entries for all, or even most, of these categories; we don't all notice the same things. For the same reason, I'm probably missing entire huge categories that I'm blind to. But I bet that at least a couple of these will spark some notes for you.

Make that list of notes, not worrying about whether they're "good ideas" or would make "good talks"; no one will see this list. (Unless you write a post like this one in five years, but even then you can choose a less-embarrassing example like I did!) When you scroll through your _ideas.key, I bet you'll find something that can be a talk.

It's hard to know which ideas will become useful later. Sometimes, an idea is so compelling that I draft a talk on the spot. Other times, I build a talk by going through _ideas.key and looking for a couple ideas that seem related. As examples, here are the core ideas that I used in some of my favorite talks:

• For Boundaries, it was the relationship between test isolation, pure functional components, and small imperative shells to combine the former.
• For The Birth & Death of JavaScript, it was the relationship between the immanent existence web assembly languages and the universality of compilers. The implications of that relationship surprised a lot of programmers, especially back in 2014.
• For Ideology, it was the relationship (and really the dissonance) between what programmers claim to believe and what they seem to actually believe. This is explored via a second relationship: what people seem to believe about categories (types) vs. examples (tests), and the resulting contradictions.

If you've never given a talk and are thinking about starting, now is your chance. Deconstruct's call for proposals is open through January 31st, 2018, at 11:59 PM Pacific time. We're an unusual conference: most of our speakers are invited, so we introduce balance with a CFP that's open to first-timers only. We cover all travel expenses, we provide mentoring to prepare you for your first talk, and we pay you the kind of speaker fee normally reserved for keynote speakers (and even then, only sometimes).

Make yourself an _ideas.key (or _ideas.ppt; we don't judge). Find the most interesting note, or maybe two that are connected in some way. Spend 30 minutes to talk through a summary of the idea, two minutes each time, for ten repetitions, until you have the core boiled down into a clear statement. Then send us a video! Once your talk is accepted, it's time to prepare the talk itself.