clark newell

First Technical Talk | Clark Newell

First Technical Talk

by Clark Newell

January 28th 2020

SLC Public Library from Wikimedia

SLC Public Library from Wikimedia

TLDR: Public speaking, especially a technical talk in front of peers and pros, is rough but it's a rite of passage every professional must experience.

A few weeks ago, I gave my first professional technical talk at the Salt Lake City public library. It was a 1-hour presentation at a popular meetup for developers in Salt Lake City, which is UtahJS. Prior to this, the longest presentation that I had given about anything software development or technology related was 10 minutes, and that was my capstone presentation at the end of web development bootcamp. In general, I believe it’s expected that anyone wishing to advance their personal growth and career usually ends up volunteering or being asked to speak, especially in the developer community. The pathway to public speaking normally begins with a “lunch and learn” or team enrichment type settings at work, moves next to a meetup-type setting and eventually progresses to conference engagements.

I’m happy to say that I have checked that box and got my first meetup presentation successfully behind me. I am grateful to the organizers of UtahJS for giving me the opportunity. Overall, it was a really great experience.

“I took a risk and decided to give a talk about a subject I was really interested in but didn’t know too much about. Within a few weeks of taking the speaking assignment, I had a working demo!”

What went well

  • Unlike my capstone presentation where I was physically shaking, which caused my voice to very obviously shake, I was very calm and confident 99% of the time. Whew!
  • I took a risk and decided to give a talk about a subject I was really interested in but didn’t know too much about. Within a few weeks of taking the speaking assignment, I had a working demo!
  • I tested my demo on the laptop I intended to use for the presentation at least 24 hours in advance. Good thing I did! Since my internship at a very Microsoft-centric shop, I had become accustomed to doing development work on my PC desktop and had hardly touched my MacBook for over a month. I remember one of the developers at my former company noticed I had nonchalantly upgraded to Catalina OS and he literally said to me “you’re a brave soul.” It wasn’t until I tried to run live code that I found out why. Upgrading to Catalina will destroy your development environment, but I didn’t know that it had. As always, Google is your friend. I had visions of wiping and restoring my MacBook back to the previous OS, but in just a few hours I had corrected a few problems with my terminal and Oh-My-Zsh and I was back in business (Oh-My-Zsh is an open source framework for ZShell or “Zsh” a Unix based shell for the command line. I was already using Zsh but the OS upgrade still messed with my configurations, anyone still using Bash on Mac would have to switch to Zsh on Catalina OS.)
  • I had prepared a great slide deck
“When presenting live code, you must change your text editor to light mode and increase the font size, same goes for the terminal window. No one is going to care how tricked out your text editor or terminal window are if they cannot read your code from the back row.”

What didn’t go so well

  • Live coding…here comes the MAJOR FACEPALM NEWB MOMENTS and the key takeaways from this experience that you will want to learn from if you haven’t already:
  • When presenting live code you need to increase the size of your text editor so the audience can read it. Have this prepared, preferably tested, and ready before your talk
  • You may think your super awesome dark mode theme with tricked out neon fonts is amazing, BUT the audience cannot read it. I know this because they had to tell me so. There is nothing like getting immediate feedback
  • You will need to switch to light mode with font in “normal” or better yet, dark colors and again, increase the font size
  • I was also demo-ing command line syntax as well as terminal output from said commands, and I quickly realized the same goes for the terminal. Increase the font-size, change it from your “super neat” opaque mode to a totally dark screen or maybe even a white screen with dark text. If you have crazy fonts (that are cool probably only to you) you may need to temporarily change the theme of your terminal as well)
  • No one is going to care how tricked out your text editor or terminal window are if they cannot read your code from the back row
  • After you have tested your code, hard-clear your browser cache or else your audience will see the after state, before the before state 🤦🏻‍♂️
  • A couple of times, I temporarily become a little nervous or flustered for a few seconds when something wasn’t working and felt myself becoming overly animated exposing a few nervous ticks, but I’m pleased to say that I got back on track and under control pretty quickly
  • I can confidently say that I did not procrastinate my preparation for the talk. Nonetheless, I was not as ready as I wanted to be. I only thing I could have done better is made sure I had a fully working demo before volunteering to talk, but the opportunity came and I decided to jump on it. Normally the slots for this meetup are filled months in advance
  • While my demo was working, it was not visually stunning. I gave the caveat that this was a talk about a hot new JavaScript framework, and not about styling and CSS (Cascading Style Sheets). But, let’s face it, we all know if a website or software UI (User Interface) isn’t decent, it’s not going to be taken as seriously or be as impressive. 😢
  • I did not do a practice run through prior to my presentation. To my credit I had scheduled it with a technically savvy friend who would have been a great critic. Unfortunately, I had to cancel because the hours I would have spent practicing with him the night before the talk were used reconfiguring my development environment on Catalina OS as mentioned above
  • I nervously stumbled answering a few questions, and after my presentation, I had a super senior developer discreetly correct me on something I had gotten slightly wrong but, I’ll happily take the feedback and learning opportunity
  • Search and study technical talk tips. Having been to countless technical talks before, I thought I had enough reference points to skip this step. I shouldn’t have
  • Just before your talk, do something other than last minute tweaking of your demo or slide deck. You risk making breaking changes, or in a nervous and flustered state, leaving your power-supply still plugged in at the coffee shop, which even for an aftermarket one, is still a $25 mistake

No matter who you are, I think it’s safe to say that everyone has a few blunders when giving their first technical talk. But, it’s a right of passage that all developers must pass through. Don’t be afraid to volunteer and do it though, you’ll be glad you did. You’ll already start looking forward to and planning your next speaking assignment, and guaranteed, it will go much better than the last time around.