FOMO is the only reason people attend conferences, which is why I visited a few to figure out whether I was missing out on anything. Speaking at a conference? Same story. You do it, because it's for "personal development", until it's pointless. Conferences have n00bs and PMs, not the experts, because they don't need to learn anything anymore.
> Conferences have n00bs and PMs, not the experts, because they don't need to learn anything anymore. The real experts never stop learning. Some of them go to conferences because that's one of the few times in the year they can hang out with each other, and find out what their community is up to.
So you want to speak at software conferences?
121–130 of 136 posts
Re: So you want to speak at software conferences?
#122[0]: https://github.com/bjoli/RrbList/tree/main/src/Collections
Re: So you want to speak at software conferences?
#123Earlier quoted context omitted.
> 9. render the presentation as a pdf file, so any device can display it That's good as a backup, or for simpler presentations (in a good way!) but Powerpoint allows you all kinds of benefits like animations or transitions. Presnting PDFs is not guaranteed to be pain free as well, as I expereince on my corporate controlled laptop with stange versions of Adobe software. > 11. the anxiety goes away It does! also rememb…
> Powerpoint allows you all kinds of benefits like animations or transitions I know. I just go for very basic stuff - large fonts, black text on white background, no border, no colors. I ruthlessly eliminate everything but the point I'm trying to make.
A ~100ms transition where the first diagram moves from its place on the first slide to its place on the second slide ensures that a person looking at the slide understands very intuitively which of the two diagrams is the original, and which one has been added. It's not perfect (e.g. you'll miss it if you're not looking at the slides at the time), but for diagrams or code samples you generally want the audience to be focussing on the slides, so it typically works well. And in 90% of cases, even if you do miss it, it'll be obvious after a couple of moments' thought what's going on, but the transition saves you those couple of moments.
I could just show both items on the first slide, but I find it's often pedagogically useful to explore the initial state by itself, rather than jumping straight in with the comparison. That way you can motivate the comparison more clearly by identifying the issues with the initial state (be that a code sample, a diagram, whatever), before moving on to the comparison with a potential solution.
If it weren't for this one use-case, I'd probably also switch to PDFs, because I've been bitten by presentational issues before that would have been a lot easier to solve if the presentation had just been available as a PDF.
Re: So you want to speak at software conferences?
#124Some things I've learned over the years: 1. do not show a slide full of code. The font will be too small to read. Nobody will read it 2. don't read your slides to the audience. The audience can read 3. don't talk with your back to the audience 4. make your font as big as practical 5. 3 bullet points is ideal 6. add a picture now and then 7. don't bother with a copyright notice on every slide. It gets really old. Besi…
What is the best way to show code? I really want to show some code. Like 4-5 lines to give a gist.
But already 7-10 lines is stretching it, and any more than that, and it's a lot harder to get your point across because people spend so much time trying to parse the code sample.
The problem is that cutting down the code and coming up with an example that explains everything you want in just 4-5 lines is really hard — "if I had more time, I'd have written a shorter letter" and all that.
Re: So you want to speak at software conferences?
#125Re: So you want to speak at software conferences?
#126Some things I've learned over the years: 1. do not show a slide full of code. The font will be too small to read. Nobody will read it 2. don't read your slides to the audience. The audience can read 3. don't talk with your back to the audience 4. make your font as big as practical 5. 3 bullet points is ideal 6. add a picture now and then 7. don't bother with a copyright notice on every slide. It gets really old. Besi…
#8 - If someone absolutely insists on a demonstration and otherwise has to "do it live" this makes you look like a god on stage - https://github.com/sloria/doitlive Basically just schedules whatever code you want to run so when you invoke the script it will step through whatever you want to run no matter the keystroke you make. No mistakes!
Re: So you want to speak at software conferences?
#127Earlier quoted context omitted.
it's physically painful for me to stop talking about my topic
it's physically painful for everyone else to listen to you talking about your topic.. if you talk for too long that is. :)
I've made that mistake. Talking for longer than 50 minutes is a bad idea.
Re: So you want to speak at software conferences?
#128Earlier quoted context omitted.
> Powerpoint allows you all kinds of [things] like animations or transitions Those are not benefits. Do not do those things. Anything more complicated than embedding a video is a distraction and will not help your presentation. (And the video can be done by alt-tab to VLC or linking YouTube or ... .) Seriously, trust me on this one. I have seen a lot of presentations in my day, from sales engineers trying to sell me…
> Those are not benefits. Do not do those things. > The best speakers really do just never bother with it in the first place. This person has a preference which is not universal despite them stating it like a universal truth. I have also watched hundreds of presentations (and presented dozens), so I'm at least as equally qualified to say: A fade between slides, fading-in bullet points or a picture on a slide as they…
Re: So you want to speak at software conferences?
#129Some things I've learned over the years: 1. do not show a slide full of code. The font will be too small to read. Nobody will read it 2. don't read your slides to the audience. The audience can read 3. don't talk with your back to the audience 4. make your font as big as practical 5. 3 bullet points is ideal 6. add a picture now and then 7. don't bother with a copyright notice on every slide. It gets really old. Besi…
> 8. avoid typing in code as part of the presentation, most of the time it won't work and it's boring watching somebody type As usual, thumb rules exist to protect you until you can confidently break them. One of the coolest presentations I've seen was several years ago at a React conference where the speaker live coded an electronic music and light show using React. They were demonstrating how "components" could rea…
1. novice follows the rules because he's told to
2. master follows the rules because he understands them
3. guru transcends the rules because he knows their limitations
Re: So you want to speak at software conferences?
#130Earlier quoted context omitted.
What is the best way to show code? I really want to show some code. Like 4-5 lines to give a gist.
4-5 lines can be really effective. After all, if you're at a software conference, you're probably speaking to a bunch of programmers about programming, and code is your universal language. But already 7-10 lines is stretching it, and any more than that, and it's a lot harder to get your point across because people spend so much time trying to parse the code sample. The problem is that cutting down the code and coming…