Jacob Tomlinson
As software engineers we should all be able to communicate the things we have built to others, but giving a formal demo of something you’ve been working on can be daunting. Mini demos are a great way to build muscles around giving ad-hoc demos with little to no preparation.
Demos don’t just have to be for conferences or planned sessions. They don’t have to take much of your time at all.
I love seeing what the people around me are working on, even if it’s in a super rough state. So I regularly encourage folks to take 5-10 mins at the end of team meetings to share their screen and show something. It can also help the demonstrator see things from a different angle by describing the work to others, sort of like demo-style rubber-ducking.
I discover new command-line utilities and software libraries by watching demos. I gain a deeper understanding of what I’m working on by demoing it to others. I learn more about the broader ecosystem I’m working in by seeing people share their screens.
But being able to just share your screen and run through something with no preparation takes a bit of practice, so here are some tips to help you give effective ad-hoc demos.
Mini demo tips
Start with why
Start by explaining why you’re working on the thing you’re showing. Who is it for? What does it do? What problem does it solve? If you’ve been working to solve a problem you should be able to quickly describe it in a few seconds without any preparation.
Multi-task
While you’re setting the scene and explaining why you’re doing something get your environment set up. Share your screen, open your editor, hammer ctrl-+ to make the text as big as possible, activate your environment, all while you’re talking. It doesn’t matter if it’s messy or takes a minute, just be sure to talk while you do it to hold people’s attention.
Set the scene
If your feature builds on another then quickly show the other feature to give some foundation. If you’re fixing a bug try and check out main and run the MRE to show the problem.
Say what you found hard
Be vulnerable when you’re talking. If you didn’t understand something or you’re still stuck on something then tell everyone. We all get blocked 10 times a day, but it’s tempting to present a demo as if everything went smoothly. If you share your pain points it will either help others learn about those problems, or share solutions if they’ve encountered them before.
Don’t waste time
If things aren’t going to plan or your demo isn’t working then just abort or pivot to something else. Demos go wrong all the time, we should all feel comfortable with that risk, but watching someone try and debug something they expected to work is no fun.
Move on, gloss over problems or just talk about what it should’ve done. Often when demos go wrong the presenter learns something, and that’s a big part of the value of mini demos, but they should circle back to it later.
Example
Here’s a quick example mini demo that I recorded just before writing this post. Hopefully it gives you an idea of how I demo things in team meetings and shows how rough and ready they can be.
Wrap up
Mini demos are intentionally unpolished. Don’t worry about them not going to plan, I’m not sure that’s even possible if there is no plan in the first place. They are just a brain dump of a problem you’ve been thinking about or a solution you’ve built. Taking the time to get that out of your head and share it with others can be valuable to everyone.
Good demos can lead to new solutions, better communication, and perhaps a desire to prepare a more polished demo for a wider audience.