Start Speaking!

Becoming an outlier developer is an ongoing process that involves learning from others and sharing what you learn. There’s no better way to engage with your local developer community and share your knowledge and passion than to speak at a user group or conference.

I recently gave a talk at my local .NET user group. It was my first attempt at public speaking and it was terrifying to present for two hours in front of a hundred people. But it turned out to be one of the best experiences I’ve had in my career; and I can’t wait to do it again.

Anthony Chu Speaking

I hope that by sharing my experience I can help others take the leap and give speaking a try.

Getting Involved

Local user groups are a great place to start speaking. The groups are usually friendly and supportive to first time speakers. I had attended a few events at the .NET BC User Group in Vancouver and approached the organizers about the possibility of presenting. To my surprise, they welcomed the idea and it wasn’t long before a date was set.

I wanted to pick a topic that I’m comfortable with, passionate about, and that is relevant to the audience. With me spending a great deal of time in ASP.NET and with the majority of the audience web developers, I had decided on a topic – “What’s new in ASP.NET”. I wanted to share all the exciting new changes to ASP.NET, Visual Studio, and Azure, and how they fit in with the web shifting to single page applications and frameworks like AngularJS.

Creating the talk

The next step was to decide on the type of talk. Because I’m more comfortable coding and enjoy presentations that contain a lot of demos, I decided I would spend about 30 minutes in slides and the remaining 90 minutes in live code and Azure demos.

Creating the slides and demos took a solid month. I have a new-found appreciation for the amount of effort conference presenters put into every talk. The slides and demos need to be crafted carefully to tell a story without being too complicated.

At my first dry run, my talk was 3.5 hours long. While it was disappointing to cut out half the material, it turned out that removing parts that didn’t fit had actually improved the quality of the presentation and created a more focused story.

A good way to reduce the time is to come up with ways to write code during demos without actually writing code. I created dozens of code snippets in the Visual Studio Toolbox that I could just drag into the code editor.

Practice, Practice, Practice

One of the things I did to prepare for my talk was watch John Papa’s “The Art of Public Speaking and Effective Presentations” course on Pluralsight. It’s a fantastic course with lots of great tips and information. One of the best tips turned out to be “know your demos cold”. I practiced each of my demos 8-10 times. It was a great opportunity to fine-tune the process while committing all the steps to muscle memory.

At large conferences, speakers are usually given an opportunity to connect their laptops to the projector and test out the equipment. User groups generally don’t offer this; but try to insist on visiting the room about a week before the talk. I was able to test out my laptop’s connection to the projector and figure out the optimal resolution settings. It was also helpful to get a feel for what it’s like to be at the front of the room so that I could visualize it during my practice runs.

Practicing the demos also helped with timing. I was able to create a script with pretty accurate time estimates. This was really valuable during the talk as it was my primary time management tool. I was able to adjust the pace because I knew exactly how I was doing with time. There’s nothing worse than having to rush through or not finishing a demo because of time… Giving a talk is telling a story and it would be a shame for the audience to miss the ending.

The Big Day

I was nervous on the day of the presentation. I remember I wasn’t able do anything productive during the day at work. I made sure I got in a good sleep the night before and spent most of the day practicing the demos one more time.

I arrived at the room an hour before the start of my talk. To my surprise, there were already a few people in the seats. I got the equipment set up and started chatting with the crowd. It was a good way to get comfortable and get to know my audience before the talk began.

The talk was two hours long but it went by really quickly. I was so nervous that I don’t remember much of it. I did remember, though, that I kept thinking “wow that’s a lot of people… and they’re here to see me so I’d better not mess up!” and each time I would lose my train of thought. That was where the hours of practice really saved me; even though I had trouble focusing, I was able to deliver the talk and demos naturally from memory.

The questions from the audience turned out to be the best part. They gave me a break from the presentation itself and allowed me to do what I love to do most… have conversations with others about technology.

Ask for Feedback

At the end of the talk, I asked the audience fill out surveys. Like any learning process, the only way to improve is to gather feedback and continuously adjust. The responses were wonderful and it was nice to see many people asking me to give more talks.

The Best Way to Learn

There is so much truth in the saying that “the best way to learn is to teach”. The talk not only allowed me to share my knowledge with others and get them excited; I had learned a lot from the experience. It has also increased my visibility in the local dev community and introduced me to dozens of people I otherwise would not have met. If you have ever thought about speaking at a user group or conference, give it a try!


  • Practice the demos
  • Bring a clock and write times on your script to help stay on track
  • Bring a bottle of water
  • Install Zoom-It to zoom into small areas of the screen
  • Enlarge the fonts in Visual Studio. (Use the PresentOn command in Productivity Power Tools)
  • Check out the room and equipment ahead of time
  • Bring connectors to all types of projectors in case of room or equipment change
  • Create snippets for code demos rather than typing on stage, nobody wants to watch you type. I stored all my snippets in the Visual Studio toolbox.
  • Ask for feedback
  • Did I mention practice the demos?
  • Have fun!


4 thoughts on “Start Speaking!

  1. Hi,

    Thanks for sharing it. It gave me inspiration to speak! I am sure it will really help others.
    Once again thanks!!

  2. Congratulations on your first speech Anthony! Another thing that I’ve done in the past to help with speaking is to join the non-profit Toastmasters. Your speeches at Toastmasters are generally 5 to 7 minutes and everyone in the club gives you written feedback and someone gives you a formal 2 to 3 minute evaluation.

  3. Congratulations for achieving such a huge success in your life. And very well said that you have to practice a lot to hit the goal. A very precisely written piece of information, it is very helpful for me. Thanks.

  4. You’ve hit most of the things on my own checklist when it comes to speaking at events, the only one I would add is to always assume there won’t be any network connectivity.

    I’ve seen so many speakers get disrupted because a video on Youtube won’t load, or a package manager can’t install a component, or even not been able to check an email to complete a live demo of a signup process.

    If you *need* Internet, it’s always worth seeing if there is a cable connection, or a seperate wi-fi network for speakers/staff , but even then external services go down so make sure you have a backup plan just in case.

Comments are closed.