Since TheDevConf two weeks ago, I'm having daily conversation with developers. All of them with over 10 years of experience, several with over 20!
One thing that I noticed is that the majority of them want to build a reputation.
Maybe it is my influence, and the fact that I distributed
"The Reputation Formula" stickers during the conference, so, I may just be really biased. Yet, developers with more experience seem to understand the value of reputation.
No matter their goals -- build an international career, increase their salaries, work with amazing technologies, join a top company -- it seems devs understand that beyond a certain level of expertise, it is not about learn learn learn.
It is about building a reputation.Towards that goal, my mentees were having a discussion the other day about presentations and how to tell a story.
Yep, being able to create an amazing presentation and telling a great story is a skill that will make wonders to your career. It will help you connect with people and inspire them. It works
in events for sure, yet, it is an amazing skill to build your reputation inside your company too.
What brings me to a special guest...
A few days ago, in a discussion in a private group, the amazing Josh Long wrote a piece that I though it was a master lesson on presentations and stories.
Josh was kind enough to let me reprint his lesson here, that you can see bellow with some emphasis and formatting added for easier reading.
With you, the amazing Java Champion and Spring Developer Advocate, Josh Long:
=====
Tell people a story, with your voice and in your voice, with you in the story.
What do I mean? Well...
I always want to
tell a story with a consistent through line. Things need to flow.
So I really like outlines in a text file in Sublime or a text editor to help draft my story. I don't use MS Word or some word processor because then I might be tempted to fidget with formatting instead of focusing on the message.
I need to be able to move things around quickly – cutting, pasting, deleting, etc. – so that the final story works. I need to see the whole story in one place. This is really hard to do with slides. You're only seeing one page at a time, not the whole thing.
This is how I build a story.
I don't do slides, most of the time. But, if I do them, I try to remember that they are a visual medium, and I use them just for diagrams or visuals. The moment you start writing bullet points, the slide doesn't need to be there.
Most of the time, the visuals I want to show are on the internet. So, I just set them up as bookmarks in a browser. On the rarest of occasions, I'll use animations.
I convey the story with
my voice, not my slides.
Then I practice the talk a few times until I get to the point where I remember the items in the outline in the right order. Eventually, I don't even need the outline. Just the visuals. And the visuals are bookmarked, so
no slides needed for them either.
Also, be quick. Remember, people stop watching YouTube videos if the screen doesn't change in 15 seconds. The screen needs to keep moving, or you'll lose them.
If you're
going to do slides, you need to do a TON of slides.
The pace is another reason why you shouldn't do bullet points. Have you ever tried to read something that requires focus while someone is talking to you? Imagine having to do that for an hour. You'd come away irritated and not particularly well informed because it's hard to keep everything straight.
I suppose the most efficient way to convey knowledge with bullet points is to show the bullet points, and then shut up, so they can read them without distraction. But what kind of conference "talk" is that, where you don't talk?
If they need to read them, you'd probably need to leave the bullet points on screen for more than 15 seconds, too. So they'd get bored. If it can be done with bullet points, it could be done as a blog.
Avoid bullet
points/slides. Talk, and use visuals. This way, people can engage visually and aurally with your story.
Don't discount how important it is that you're
you in the story. If you're telling a story, then
be a part of the story. Be the proxy for the audience as you walk through the story.
You're not just a voice narrating the scenes for them to experience it – you're in the story with them.
They won't engage with your code if they can't engage with
you. There are lots of reasons why they can't engage with you. Lizard brain stuff still applies here, too. If people sense you're not confident in what you're saying – because you haven't rehearsed or
practiced or whatever – then they won't dive fully into the water with you.
Stage fright is a real thing. It's our lizard brain telling us to run away when we are surrounded by creatures who we don't know. Fight or flight. You overcome this with practice, which breeds confidence.
One of the easiest ways to gain confidence is to be sincere. Be yourself.
You want people to engage with you. Be at the
center of the story. You're not looking at the new feature X, Y, or Z. You're telling them about
your experience working with X, Y, or Z. If they like you, and they see you're having fun, they'll want to do what you're doing to have fun too. Monkey see,
monkey do.
As some examples, I could listen to Dr. [Venkat] Subramaniam or James Ward or Trisha Gee read the phone book and still engage because I feel, and I'd bet, that they've got fun perspectives to inhabit, and I'm excited to join them on another adventure.
Be in the story.Or, you could write a blog.
Thanks,
Josh Long
=====
N'uff said.
You really should follow Josh Long on YouTube and Twitter.And, if you are interested in speaking and building your reputation, I wrote a little book,
Low Hanging Talks, that focus on helping tech professionals like you to speak better (or to start speaking).
Just grab the book for free here:
https://jav.mn/lowhangingtalks