My first tech talk. A step outside my comfort zone that paid off!

Two years ago, I wrote my first JavaScript function. A year and half ago, I got my first job as a front-end developer. Three weeks ago, I had my first tech talk at a JavaScript conference. I’ve already written a post about the first two things. Now, I want to share with you my experience from my first tech talk. I’ll talk about my motivation to apply, the application to the conference, the preparation of the talk and about the presentation itself.

I would like to take you six months back and tell you a little bit about why I even applied to the conference in the first place. Maybe you’re waiting for me to say something like: “I always wanted to speak at conferences…”. However, this isn’t the case.

One of the things I love about programming is the community. It’s the community that is helping me become a better developer. However, the community can work only if its members constantly return their experience, projects, or anything else back to it and share with the rest of the community. Each community needs givers who help the community to move forward. And all of this applies to the community of developers as well.

Back to the original question. I applied to the conference because I wanted to share my knowledge with the community.

The first step was to think of a topic. I knew that it should be a JavaScript talk, and that it must somehow be related to React, since I work with it a lot. The talk also needed to be useful for fellow developers in a way that they would gain new knowledge. Since I was using the higher-order component pattern a lot during the application development of my side projects as well as at work, I decided that this could be a great topic.

The second step was to write the proposal. I thought a lot about it and spent a couple of days writing and rewriting it again and again until I was happy with it. Finally, I sent it to four conferences and waited for their responses.

In hindsight, my decision to apply might seem a little bit crazy. Imagine my situation at the time of the application. I had only been programming for 18 months and had no prior experience with tech talks whatsoever. However, this doesn’t mean that I had never presented in front of an audience before. When I worked as a lawyer, I had a few presentations, but mostly in front of a handful of people and in Czech.

As a result, my confidence in my ability to publicly speak about programming in front of so many people was not that high. Moreover, the idea that I’d be speaking in front of so many experts was even scarier.

Maybe you’re asking why I didn’t go to some local meetup first. If I had, I’d have definitely been less nervous. I guess it’s natural to speak in your native language in front of a smaller audience first. However, I chose a different path. I applied to four conferences held in English throughout Europe.

After a couple of weeks, emails started coming. They were rejection emails. However, I was still waiting for a response from one last conference. I decided to visit their site and to my surprise I found that my talk had been accepted. I really couldn’t believe it. I thought that I just didn’t understand what I was reading since I hadn’t received any email yet. However, after a couple of hours, I got an email saying that I had been accepted as a speaker at the International JavaScript Conference that would take place in Munich, Germany.

I had roughly five months to prepare my talk. Did I mention that it was supposed to last for 60 minutes? Talks at most conferences take approximately 30 minutes. Not my talk. My first tech talk would be two times longer! Sweet.

As I’ve already mentioned, the talk was about higher-order components (HoCs). The main idea was to show the audience how HoCs could help them to develop maintainable React applications.

I started by reading every relevant resource I could find. This means a lot of code, articles and blog posts. I’ve also written a lot of code myself. When I acquired enough resources, I began writing the first version of my talk.

I did all of this in my free time, after or before work. The closer the conference got, the more of my spare time I invested into the talk preparation.

Three weeks before the conference, I had the final version of my talk. At least, I thought I had. I asked my friends for feedback, which turned out to be pretty helpful.

The next step was to practice the talk itself – starting with rehearsals. When I tried it for the first time, it took me an hour and 20 minutes. Honestly, I was kind of glad since I had kept some paragraphs just in case my talk turned out to be too short. Since this wasn’t the case, I could simply delete them. The second time, the rehearsal took me about 50 minutes. This was perfect. I still had 10 minutes for Q&A.

During the preparation, I realized that public speaking isn’t just about the content of the talk but also about its presentation. If you’ve got a revolutionary idea, but you’re not able to deliver it in a convincing way, you might fail to succeed in sharing it with others.

I started reading TED Talks: The official TED guide to public speaking by Chris Anderson. This book was priceless and I recommend it to everybody, not only to speakers. It covers the process of writing the talk as well as its presentation and it goes really deep. It definitely made me more confident and helped me think about the aspects of my talk that were not obvious to me before.

For example, I added a pancake metaphor in my talk. I compared the presentational components and the HoCs to pancakes and their sweet toppings. Just as you can decorate your pancakes with various decorative layers, you can decorate your presentational components with different HoCs depending on what logic you need for a particular use-case.

This metaphor turned out to be a very good choice. Not only did it lighten the talk a little bit, but I learned that it helped attendees to understand HoCs better. There’s even a tweet by the conference about it.

One week before the conference, I learned that the capacity of the lecture hall where I would be giving the talk was a hundred people. Due to my lack of any comparable previous experience, it was difficult for me to imagine that I’d be speaking in front of so many JavaScript professionals. However, I guess it doesn’t make much difference if it’s twenty or a hundred people.

Before I realized how much time remained, I found myself making final preparations at the conference venue in the center of beautiful Munich, in the heart of Germany. My talk was scheduled on the 3rd day of the conference, so I still had some time to rehearse.

In hindsight, I didn’t underestimate my preparation since on the day of the talk, to my surprise, I wasn’t that nervous. I arrived at the lecture hall 20 minutes early, prepared my slides, asked the organizers to adjust the lights and waited for the people to take their seats.

The talk itself went smoothly. It took me about 52 minutes. Afterwards, I answered a couple of questions from the audience and I was done. Mission accomplished.

This whole conference talk venture was a step outside my comfort zone and it helped me to move forward. During the whole process, I learned so many things that will help me and not only in my programming career. My confidence improved a lot as well since I know I’m now able to give a public talk about programming for almost an hour in front of many professionals. Moreover, being a speaker made the conference a lot more awesome.

It was rewarding for me in two ways:

  • I found out that I’m able to share my knowledge in front of quite a big audience.
  • I learned a lot not only from the other speakers but from the attendees as well.


When I initially got accepted to the conference, it was difficult to imagine myself speaking about programming in front of a lot of anonymous people. Now, I’m really looking forward to it!

If you want to move forward in your career as well as in your life, I recommend you to step outside your comfort zone, and discover the beauty of public speaking.

Leave a Reply

Your email address will not be published.