I bet that’s not true.
I used to think that, especially during my first year of being a software developer. I wanted to speak at tech conferences. I’d done presentations and debating at school and university, so I thought I’d be good at it. But what did I, a junior developer, have to say about tech that was interesting?
So, I stuck to running the weekly Lunch & Learn events at Pivotal, where I then worked.
One day, a colleague was organising a talks night at the monthly London Cloud Foundry (Pivotal’s Platform-as-a-Service) user group. The talks would be 10 minutes long. He said to me, “You’re always organising events here, but never speaking at them. Speak at this one.” I panicked. I couldn’t think of a decent enough reason for saying ‘no’. Besides, a 10 minute talk wasn’t that long. It would be an accessible length to ease myself into the world of speaking at tech conferences! And before I knew it, I found myself saying ‘yes’.
Turns out that it doesn’t matter what the length of the talk is. If you don’t have an idea that you’re confident in, filling even 2 minutes can be a serious endeavour. As soon as I agreed to take part, I started thinking about what I was going to speak about. I spent weeks mulling over this, but I could only think of two things: 1) my experiences as a junior developer, and 2) the pain of slow feedback cycles — at the time, the test suite on my team lasted for over an hour.
I wasn’t excited by either of these options. For the first option, I’d seen a lot of talks by junior developers about what it was like being new in the industry and I didn’t want to choose what seemed, to me, to be the easy, obvious option. I wanted to demonstrate to an audience of more senior developers that they could learn something new from those coming into the industry, beyond just a better understanding of what our experience and perspective was like.
For the second option, I didn’t think I had anything new or insightful to say about why slow feedback cycles were painful. One of my worst fears when giving a talk is for the audience to sit there and think: Duh — this is obvious. Why have you wasted my time?
At this point, not being able to move beyond these two ideas by myself, I almost pulled out.
But then I realised I had all of these smart people around me at Pivotal, so I figured one of them would give me my grand idea. I started to ask my colleagues for ideas and got two general responses:
- “Talk about the fact that you’re junior and what it’s like.”
Well, I’d already decided I didn’t want to do that. The fact that it was a very popular suggestion confirmed my belief that it was the easy and obvious choice for me.
- “What’s something that’s currently frustrating you at work? Talk about that.”
So I was back with the slow feedback cycles. And I’d already decided I didn’t want to talk about that either.
It was at this point, two weeks away from the talks night, that a cold panic set in.
It was true. I had nothing to talk about.
Have you heard the story about the two university students…
…and their final Chemistry exam?
They had received A’s all term. But on the night before the final exam, they went partying in another town and didn’t get back to school until the exam was over. They had to think of a legitimate excuse. They thought about what to say before finally going to their professor and saying: “we’re really sorry, we went to visit some friends the evening before and would have made it back in time, except for the fact that we had a flat tyre. Can we please sit a make-up test?”
To their surprise, the professor agreed. She wrote out another test for them to take the following day and, when the time came for them to sit it, she sent them to separate rooms.
They each sat down and turned the page to the first question. It was worth 5% and very easy. They answered it quickly and turned the page to the second question:
Which tyre was it? (95%)
Stories like that got me into Game Theory.
I studied Economics at university. Game Theory stood out because you could take entertaining stories from everyday life and attach a model of strategic interaction to them. These models could provide an explanation for why things happened as they did, help you to think about likely outcomes based on the behaviour of others, or guide you in deciding which actions you should take.
Take the students in the story above. They now find themselves in what’s called a coordination game — one where the players do best when they choose the same strategy. If they land on the same tyre, the professor will give them the benefit of the doubt that they were telling the truth and they’ll pass their end-of-year Chemistry exam with flying colours. However, if they put down different answers then the professor will know they were lying — and so they’ll fail the exam.
The students are in separate rooms at this point. There is no way they can communicate. They have to think — what is the other person likely to put and why? Maybe one of the students, student A, knows which tyre is more statistically likely to go flat in their country — but that answer is no good if they don’t have confidence that student B also knows that information and knows that student A knows it too.
Coordination is just one flavour of game. One type that I found particularly interesting were bargaining games. In its simplest form, a bargaining game looks at how two people will share an amount of something, usually money.
Why did I like bargaining games so much? A lot of our day-to-day interactions revolve around a negotiation of some form, whether you’re trying to get a raise at work or go to your favourite restaurant when deciding where to eat with a group of friends. I liked that Bargaining Theory explored how the stuff in question should be shared, based on the specific criteria that you want to optimise for, as well as how the stuff will end up being shared, based on the current circumstances of the game and the information held by the people involved.
So back to how I had nothing to talk about.
There was one thing I did know — I wanted my talk to be engaging. That’s what I wanted to optimise for. I thought the best way to do that would be to talk about something that most people in the room wouldn’t know a lot about.
I also didn’t have much time left at this point. I’d spent weeks stressing about how I didn’t have anything to talk about so in order to put something together pronto, I needed something that I knew a lot about.
That’s when it hit me.
Something the audience doesn’t know a lot about +
Something I know a lot about =
Game Theory.
I was making an assumption about what the audience would know, but I figured that it was unlikely that the majority of people in the audience would have an Economics degree and so would have been unlikely to have studied Game Theory to the depth that I had.
So, I settled on Game Theory. Then I thought: Game Theory is so broad — is there any way I can link it to Cloud Foundry and PaaS? — which is what I was working on at the time. So I searched for game theory and cloud computing and stumbled across some academic papers. Turns out a few Economists had been looking at the most efficient way to allocate resources in distributed systems, i.e. systems where many computers have to work together to do some work.
The papers were dense. I realised that I could take my learnings of Bargaining Theory and construct a fun story of computers as game players, characters, who had to work together to complete tasks efficiently for the users of the cloud platform.
And thus my “Playing Games In the Cloud” talk was born.
The 10 minute lighting talk was enjoyed by everyone (I think) and caught the attention of some people who pushed me into developing it into a longer 30 minute talk. I eventually first gave this at RailsConf in 2015.
I went from thinking I didn’t have anything to talk about to getting accepted to speak at the biggest Rails conference — on a topic that had nothing to do with Rails, mind — within a matter of months.
So back to how you have nothing to talk about.
I bet you do.
Sometimes people tell you: think about something at work that’s frustrating you.
For my first talk, that didn’t work for me. I couldn’t find anything inspiring or exciting enough that I wanted to work at — remember, crafting an excellent conference talk takes a lot of time.
And so, if finding a pain point isn’t working for you, try this:
What’s something that you know a lot about that a room full of developers in your field will likely not know about?
It can be anything. Trust me.
Even after writing the Game Theory talk, I spent a lot of time telling myself: but nobody cares. Why do you think anyone will care? Half the room will probably leave when they realise this has nothing to do with Rails.
Some of the best talks I’ve seen over the years have nothing to do with day-to-day software at all. They don’t even tie back to computers or tech the way that I did in my Game Theory talk. These sorts of talks can often be gifts to us, as they force us to think about things and draw parallels in ways we wouldn’t have done in our tech bubbles. Our career is in problem solving — the best problem solvers have an arsenal of symbols and metaphors at their fingertips ready to help them analyse that tricky problem from a different perspective.
Give conference-goers something completely novel to add to their toolkit.
—
If you want to throw ideas around, tweet me @nodunayo. Also, if you’ve never written a conference proposal before, check out speakerline.io for examples of ones that have been accepted or rejected at various conferences.
If you’re interested in watching “Playing Games In The Clouds”, check out the 20 minute version I gave at Brighton Ruby.
Top comments (0)