I gave this talk while participating on the Women Who Code lightning talk panel on "Developer Fails" at Denver Startup Week on September 16, 2019. I gave 2 examples of demo fails I experienced while presenting on my IoT projects, and lessons learned.
https://www.denverstartupweek.org/schedule/5947-that-one-time-lightning-talks-about-developer-fails
https://www.meetup.com/Women-Who-Code-Boulder-Denver/events/264744439/
Learn more about me at: sunfishempire.com
To see the video of this presentation, go to:
https://youtu.be/GvnCu8ArmJE
1. Surviving Code Demo Fails
(It’s not the end of the world!)
🤯
Vui Nguyen
sunfishempire.com
@sunfishgurl
2. Overview
- Who am I?
- Present 2 different situations where code
demo went sideways
- one where I had more time to fully prepare
for the demo
- another was when I did not! (hackathon
situation)
- Takeaways from two very different
experiences
2
3. Who am I?
3
- Long time software engineer
- Currently doing iOS development
professionally
- Do embedded programming / IoT as a
hobby
- Intel Software Innovator
- Angler of all things fish 🎣 and shellfish 🦀
12. Demo in Final Round: 😧
12
With so many pieces to move
and so little time to set up, and
no time to test / run through, is
it any wonder we forgot one
little detail….
16. Takeaways
- For demos / presentations, practice, practice, practice!
- If you have time to prepare for a live demo, create a video
for a backup
- If you don’t have time to create a video and a live demo
goes sideways, be kind to yourself
- Always reflect on your experience, what you learned and
what you got out of it
- Take time for self-care, to reduce mistakes / failures and
for your health 💖
16
18. Credits
Special thanks to all the people who made and
released these awesome resources for free:
- Presentation template by SlidesCarnival
- Photographs by Unsplash
18
Editor's Notes
One of my IoT demo fails occured when I gave a demo on a system I built that controlled 3 LEDs attached to an Intel Edison board. And I would turn on/off the LEDs using a mobile app that I built, and also a website that I built. The UIs of the mobile app and website were fairly simple, I built this not to show off the UIs of my applications, but to demonstrate how to build an application that can control a microcontroller board. The LEDs in this case Blue, Green, and Red LEDs. I was giving this presentation at a local meetup, and for the life of me, could not connect the board to the wifi, which is necessary for the communication between the apps and the board to happen. I must have spent half an hour before the meetup began trying to connect to the wifi.
Fortunately, I had the presence of mind when I was preparing my presentation at home to record a video of my demo just in case. So, here’s the short video that I ended up showing at the meetup as part of my presentation. (Play Video)
Notice the production value isn’t super great, but it got the job done. So the takeaway lesson here is: if you do a live demo for your presentation, and you have the prep time, record a video in case things go sideways.
The next demo fail that would eventually occur happened while I was working on a system that my team and I called “Save the Water Pipes”. Save the Water Pipes is an automated faucet dripper to prevent water pipes from freezing and breaking in cold climates (a problem in Colorado). It does this by sensing when the water in the pipe is getting too cold, starts dripping the “faucet” until the temperature in the water pipe rises, and then automatically shuts the faucet off. Our first real prototype was a single unit system, designed to simulate a single family home. We entered this prototype to the China US Young Maker Competition in 2016, a contest sponsored by Intel.
So guess what? Intel selected our team as one of ten US teams to fly to Beijing, China, and enter our “Save the Water Pipes” project in the final rounds of competition! So far, so good. No demo wardrobe malfunctions …. yet. By the way, Intel did take us on a tour of the Great Wall while we were there, that’s an actual picture we took from our trip, not a stock photo. The plane on the left, tho, is a stock photo.
One of the requirements of the contest was that we had to show “improvement” in our project from when we submitted our project online and when we demo the project again during the semi-final and final rounds of competition in Beijing. In order to do that, you had to work on your project during the 24 hour hackathon in Beijing before the judging rounds in Beijing. So we went BIG! Our original prototype was for a single unit , like a single family home. We expanded our prototype to a multi-unit system, like an apartment building with many units.
Now, we couldn’t bring our entire system, fully built, in our suitcases, to China. So we had to bring the parts unassembled. Now, imagine trying to get wires and pipes in your luggage through airport security …. But as you can see, we got our multi-unit system fully developed and working, working down to the wire, pun intended, by the end of the 24 hour hackathon.
The day after the 24 hour hackathon was judgment day, consisting of 2 rounds of competition. During the semi-final round of competition, the judging was done science fair style. Each project had their own table, and groups of judges went to each table. This was great, as we had plenty of time to setup our system, and do any practice runs at our pace before the judges came. At the end of this semi-final round it was announced that we made it to the final round of competition!
This should be great news! BUT, competing in the final round meant that we had to move our system to a different room. Now remember, all the additional pieces that we added to the system to convert it from a single unit system to a multi-unit system? Well, we had a choice for how to present our demo in the final round -- show the video and slides of the single unit system, which we submitted online for the contest, but would not demonstrate the full extent of the improvements we made.
Or, take a risk by moving the ENTIRE multi-unit system (with ALL the extra pieces we added and the possibility of something not being attached correctly, etc. ) to another room to perform a live demo in the final round, keeping in mind we had NO time to create a new video before because we had worked down to the last minute during the 24 hour hackathon. But if we could demo the ENTIRE multi-unit system live, the payoff would have been huge! So, we decided to do the live demo of the full system.
Oh but there’s more! We found out, at the last moment of course, that not only did we have to move the whole system to another room, but we first had to move it to a staging area and THEN move it to the final judging room. And of course, once we moved everything to the final judging room, we had just minutes to setup and ZERO time to do any run throughs of our demo before the presentation... So of course we forgot one little detail …
Yes, we forgot to turn the thing on! We forgot to turn on the power strip, to power the solenoids that open/close the water valves/faucets in response to changes in the water temperature in the pipes. So here are talking about how our system works, just like we did in the semi-final round, while letting our system go on auto mode in the background. Except that the water faucets never turned on and off, because the valves were not powered on! So the judges didn’t get to actually see the “automated faucet dripping” in action! It was devastating, but ….
We still placed 11th out of 64 teams (and that was both the US and Chinese teams combined), in the final round of competition. We went to the Great Wall of China! We participated in an international IoT contest, all expenses paid by Intel. Why get caught up on a minor failure in the final hour of competition, given all that we’ve accomplished during the competition and the hard work we put into the project in the months leading up to it? Reflect on your experience, and appreciate what you learned and got out of it. Give yourself credit for taking a risk in doing something challenging / different instead of beating yourself up for not being perfect.
There’s going to be times when things get hectic and you just have to push on, like at a hackathon. But I wouldn’t recommend burning the candle at both ends on a regular basis, if you can help it. Mistakes and therefore “failures”, are more likely to happen when you’re rushed and / or when you’re tired. I can’t tell you how many times in my career I’d get tired after working on the same problem all day at work, that I couldn’t focus anymore. That’s when I would call it a day, get a good night’s sleep, and oftentimes a solution would just come to me when I woke up in the morning. So take time to care for yourself. And if you still make a mistake even under the best of circumstances, it’s okay. Learn from it and move on.