Dear JavaScript,

We’ve barely spoken in the past year but I still think about you. You were my first self-taught language and it built me a career. JavaScript, you taught me to let go some of my perfectionism because it’s so easy to just get started, and make something, knowing that iterations will always be necessary. And it was through you that I learned to love functional programming.

I met you, briefly, sophomore year of high school. It was before I even knew what computer science was but I met you and I knew that I liked programming. I learned Pascal, Java, C, C++, and eventually I’d come back to you.

In bits.

Over years.

College told me I’d be an embedded programmer, learn C, go to Intel. I applied to a 6 month web development internship. Finally we reconnected and you, JavaScript, started my career. 6 months turned into 3 years.

You’re not perfect and oh boy did I try to make up for it. Paralyzed, I’d sit, not sure where to start because there were so. Many. Different. Ways. To start. And that is the lesson you taught me: get started now, with something, a small version of my goal. Getting started is the hardest part but if I can do that fast, the next iteration will get me to a closer, better state.

Over and over until perfect can’t be the enemy of done.

I stood on the shoulders of those who have shot themselves in the foot and learned how to be safer in JavaScript. I saw in you what functional programming looked like. Not all at once, but little by little. Incrementally.

From so many other people who also loved you and wanted you to be better, I learned pure functions; I learned to make every variable a constant; and I learned to love your libraries of composable functions.

I learned Haskell and Elm not in spite of you, JavaScript, but because of you.

Thank you for all that you’ve done, all that you were, and all that you taught me.

You may not be perfect, but goddamnit did we grow.

For elm-conf 2019, I created a 6 degrees of Kevin Bacon inspired game for the Marvel universe. I found a Marvel GraphQL endpoint and created 6 degrees of Squirrel Girl. You can find a pdf of my slides here. Enjoy!

I was interviewed on a podcast called Functional Geekery. Proctor and I talked about my functional programming origin story: starting at my first internship, learning about Elm, and getting more involved. We spoke both about my first talk and a bit about my upcoming Squirrel Girl talk since I was in the middle of working on it at the time.

Have a listen over at Functional Geekery or your podcatcher of choice!

In April 2019 I gave my first conference talk at Elm in the Spring. I spoke about being in a brand new code base at the same time as a brand new city and showed that exploring one is similar to exploring the other.

In the past I gave smaller scale talks — a handful internally and one at a meetup. Those were all written in a very similar way:

• Write everything like a blog post
• Make slides based on the pseudo blog post
• Talk to the slides, practicing ~3 times
• Give the talk

This strategy resulted in fine talks but, for a conference, I wanted to do better. I wanted to put my heart into it and really work with some semblance of a strategy. I’m glad I did because it paid off. By creating with more intention, I gave a talk I was really proud to give.

I started my talk writing process by researching how to write a talk. I reached out to coworkers, friends, and the internet, to see what advice I could find. Through that research, two posts really spoke to me.

• How to Prepare a Talk by Gary Bernhardt suggested standing up and talking immediately, never laying pen to paper.
• How to prepare and write a tech conference talk by Lena Reinhard went so far as calculating a word count and writing every word out.

Like a pendulum, I tried both sides and wound up somewhere in the middle.

Talking to think

Bernhardt’s How to Prepare a Talk inspired me with the idea of talking (instead of writing) your talk. It preaches creating an outline organically by free talking and adding slides as ideas come up. The idea is that you run your talk every day and see how it changes and solidifies. When I work on a blog post, I usually start by free writing so the idea of free talking really resonated with me.

The very first day I started by grabbing a glass of water, finding an audio recording app, and setting a 45 minute timer. I made sure to follow the rule of free writing: just keep writing (well, talking) — it didn’t matter what I said as long as I kept talking.

On the other side of about 40 minutes of loose associations was where my idea waited for me. Through this free talk process I found the core metaphor for my talk: exploring a new city. I had just moved this year so that was that — I had an angle. I had my narrative.

I tried free talking a few more times but realized it wasn’t a silver bullet strategy for me (big surprise). Each time I spoke, my talk got shorter and shorter because I wanted The Talk™ already. I realized I liked having content I could directly edit and see. I needed a physical artifact I could tinker with and for me that is writing.

Writing to think

Reinhard’s How to prepare and write a tech conference talk had me write it all out. By getting a feeling for how fast you talk you can calculate the number of words you need to aim for — between your outline and research notes, you can use this to gauge when you have enough.

When I first read How to prepare and write a tech conference talk, I was struck by how much writing it was. I was afraid to go down that path because I didn’t want to write a ton of content that I ended up “not using” because I knew ultimately I wanted to do the talk naturally. After the free talking strategy, I realized that the goal of the word guideline was to recommend an amount of content, rather than writing a talk of an exact wording.

While experimenting with free talking, one of my problems was not having any idea how long to speak on a certain subject. By giving myself a word count for the whole talk, I could figure out how long each section should be, and then focus on just one section at a time.

Apparently I speak around 158 words per minute. Subtracting 10, as recommended by this blog post, and multiplying by 30 minutes gives me 4,440 words. That felt very intimidating at first but I kept breaking it down. If my intro and conclusion took about 10 minutes together, then that left me with 2,960 words. Okay, that’s still a lot. Broken down into four sections? 740 words each! I’ve written essays longer than that before! My new goal became writing one mini-essay a day.

The essays were key for me because that meant each session I only focused on one topic and by writing it out, I could pause and research and look back through my notes and tie things together. Initially I wrote the essays as if they were completely independent. Once they were all produced, I started reading them out loud together to see how they flowed.

Index cards to think

While working out transitions between sections in a coffee shop one day, I saw things from a whole new light: while I had been so focused on my “finding your way around” metaphor from a psychology perspective, I realized that I explored code and a city with inverse strategies. This changed my angle. However, by this point I had been writing and practicing my talk in its current form for a week and a half. I was teetering on the edge of the sunken cost fallacy and needed to take a step back.

I went home and pulled out the index cards. I wrote out each step I took to explore my new city on its own card and then sorted the notecards in order of how I explored. Then I turned my back on that pile (yes literally, I didn’t want to be biased by what was in front of me) and created a separate pile of how I explored my new code base and then ordered those.

When I brought the two piles together, I realized that they were, in fact, inverted versions of each other. On another set of index cards, I wrote an example of exploring the code for each step — some I already wrote about and some I hadn’t.

This process gave me the narrative structure of my talk as well as a visual structure. I was worried that I was changing the talk too much with “only” three weeks to go, but I realized that wasn’t true — I already wrote the majority of my content. All of the additional content came from personal experience. I was just reorganizing things. After my index card exercise, my talk did get shorter but was easier to flesh out and the flow of the talk made more sense.

Once I practiced with my deck of notecards enough times, I made a second set to mock my slides. I have found going straight to the slide deck software to be too detailed too fast so I like to start with this low fidelity version. It also lets me rearrange the slides while running through the talk without having to touch a computer and wait for things to load.

With the technical details, I’m pretty visual. While the index cards worked well for me to get a general idea they resulted in short talk times since I had no code to actually talk about. The final bits of my talk came together once I created slides and added code and screenshots to talk about. Finally putting my thoughts into a real slide deck and iterating on them really helped me solidify the content of my presentation.

Overall

Like Bernhardt suggested, I aimed to talk my talk once a day. While that doesn’t mean that I actually did speak once a day, it means I got pretty darn close.

I recorded myself speaking most times and tried to listen to it the next day while taking notes. The most effective use case was listening to my talk while going through my slides and making sure that everything I talked about got highlighted and that the presentation flowed consistently.

I started writing my talk two months before the conference, including researching how to give a talk. Two weeks before the talk was when I started getting really nervous and stressed and that caused me to work really hard. At this point I definitely doubted if I was going to be ready and if it would all be worth it.

Stress working was not great for my sleep schedule, but it did mean that I got my slide deck finalized (enough) pretty quickly so the week before my talk, all I had to do was one run a day and minor edits. That was very nice.

In that last week I scheduled time in my work calendar to give my talk and grabbed people to listen and give me feedback. This was great because it turns out that after practicing with a cat as my audience for about a month straight, I forgot I had jokes.

As far as nerves on the day of the conference went, having ran my talk as much as I had meant I wasn’t as nervous as I thought I’d be. The nerves hit me an hour before my talk (“will I throw up?”) and lasted about 30 minutes. Then they dissolved into excitement and my heart song revealed itself: Space Jam. When I was done giving my talk, I had so many endorphins pumping — it was honestly hard to focus. I had done it! I had given my first conference talk!

Was it all worth it? Absolutely.