How to Use Software Fundamentals Outside Of Programming

The background of BrazilJS 2018: My First Talk. Ever.

A snapshot from my talk on BrazilJS 2018. There's the stage on the left and the audience on the right.

BrazilJS is the biggest JavaScript Conference in the world, with an attendance of almost 2000 developers every year. I’ve participated in the event as an attendee every year from 2012 to 2016.

In 2012, I met BrendanEich, the creator of JavaScript. In 2013, I met Douglas Crockford. In 2015, I accidentally appeared on a picture from a local newspaper article related to the event. In 2016 I got an invite to talk in BrazilJS while I was an attendee. In 2018 I was a speaker.

What most people don't know is that BrazilJS 2018 was my first public talk. I didn't have the presentation skills or the experience to face thousands of developers on stage. However, I took the challenge. I accepted it under the assumption that the same software fundamentals I use every day to build software would guide me to create an excellent presentation.

In this post, you're gonna learn how software fundamentals helped me to come up with the talk. I'll show the tradeoffs and the techniques that I used to manage the time, content, and lack of skills.

BrazilJS was my first conference talk. Ever.

Given I also write these blog posts and have worked with Open Source in the past, my primary challenge wasn’t to come up with ideas for content. My biggest challenge was to figure out which kind of content would be the most interesting for an unsuspecting audience.

I can only know if something is appealing in hindsight. Therefore, I chose to make sure the content was unique. The presentation was about the technical details behind the Open Source library js-cookie and how that changed the way I look at Web development.

You can only know in hindsight if something is appealing for an audience or not.

One year ago, I wrote a post called Code Less, Think More… Incrementally. The post introduces the concept of Incremental Delivery. It shows why it’s better to have 100% of something than 99% of nothing.

However, that fundamental is not restricted only to software. You can apply it in other domains. For most types of intellectual work, there's a possibility of delivery in the form of vertical slices; create end value in the first version with the least amount of effort, then use the rest of the time as a resource to look for feedback and improve the work in the right direction.

I created the talk outside my working hours. Given time is a non-renewable resource, it makes sense to optimize for it. That's what I did. Once I chose the topic of the talk, I wrote the presentation in 1 hour using Medium drafts. That was 12 weeks before the presentation. In the next few weeks, I planned to iterate and review the work many times, in this specific order:

  1. Improve the Medium draft of the presentation.
  2. Transform the text from the Medium draft into slides without visuals.
  3. Add simple images to the slides.
  4. Transform the slides with simple images into slides with better ones.
  5. Transform the slides into an impress.js simple presentation.
  6. Convert the impress.js simple presentation into a 3-dimensional one.
  7. Animate the bullet points.

I chose to prioritize the components of the talk in this order:

1. The content, as in the core subject to present.

2. The slides, as in the visual representation of the material.

3. The presentation, as in my presentation skills.

At any iteration, I could run the talk. However, the quality of the content, slides and/or presentation would depend on how much time I had to invest and improve it. I've created a process where the work gets better over time, and the talk is always in a finished state.

The deadline to stop the improvements was the date of the event: August 24th, 2018.

Time is a non-renewable resource; it makes sense to optimize for it.

I’ve applied excessive focus to improve the content while I was still in Australia. Even with that, I didn’t manage to transform the slides into a 3-dimensional impress.js presentation.

Also, I had to present mostly in English to get feedback. There was minimal opportunity to practice my presentation skills. I didn't have much chance to practice the talk in Portuguese, which would be the language of the talk in Brazil.

Given I didn’t have time to practice, I decided to change the script and use a colloquial wording where the text would emulate precisely how I would speak naturally. This way, I could read the script, and it wouldn’t sound as bad as if I was reading a structured text.

Given I didn't have enough time to practice my presentations skills, I read the whole presentation in a colloquial wording.

Like everything in software, decisions have tradeoffs. You need to sacrifice part of one thing to focus on another. Given I didn’t have experience in presenting at conferences, every investment of time on presentation skills would reduce the time available to work on the quality of the content.

This is the tradeoff of an incremental/iterative approach: you get to have 100% of something at any time, but that won't be the best version of it. The presentation may not be as good as having 100% of what you envisioned, but it will be better than having nothing to present.

The tradeoff of an incremental/iterative approach is you won’t have the best version of your work, but it will be better than having nothing to present.
A visual representation of the content of my talk on BrazilJS 2018, by Ana Tarrisse.

In the first 15 seconds of the talk, I started reading the content as if I was reading it to someone. When I realize that I was sounding too robotic, I began to course correct and read as if I was speaking naturally. However, I couldn't take my eyes out of the script for too long, which made me run the whole presentation looking mostly at the screen.

Given there was no standard process for feedback and the talk didn't have space for questions, I can't tell with confidence if it was successful or not. However, based on the comments from the Youtube live broadcasting and discussion with folks who came to me afterward, the audience liked it.

One thing I learned from this is that even when you have the content, to build the presentation for a conference is hard work. However, you can use software principles to make the job easier.

I'm not yet convinced that public speaking is something I would like to do in the future. Regardless, this was an excellent experience to reinforce a great fundamental I've been applying throughout my whole life and all my software projects:

It’s better to have 100% of something than 99% of nothing.

Once the talk is published on Youtube, I'll post it here.

Stay tuned 📻.


Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.

Thanks to Wilson Mendes and Ian Tinsley for their insightful inputs to this post.