- the presentation is focused on the experience around writing the code. Debugging, tooling, etc. No, I don't want to see you fumble around coding. Yes, I do want to see you interact with your tools and libraries and help me learn something in the process.
- the presentation is polished and the presenter knows every single line by heart (and have complete files they can just cp into to place if needed).
- concepts of what we are going to see are established in the presentation before they are demo'd.
- as always, having the video backup won't hurt in case of network or other dependency failures. If your demo is busted and you can't recover in 30 seconds, bail. Your audience gets it and will thank you.
Start around the 8 min mark
I could see if it was set up as a lesson with everything already worked out and you're going through a recent section of a program you're working on. But thinking of someone watching me while I figure out data structures write and rewrite a few lines of code, go back change something else, stop and think for a bit, write a bit more, go back and change something, sit for a while and think, maybe consult some api documentation. Then having to watch while I try and compile...over and over...fixing every stupid mistake, correcting every misspelled function or keyword, searching for that one miscapitalized letter or finding every misplaced comma or bracket...and that's just the stuff before it actually compiles.
Then you find out everything you wrote is just totally not what it should have been. Or there's that one weird bug that shows up sometimes that takes 4x times as long to figure out as it took to originally to write.
I just feel like these things would be really boring for someone to watch me do unless I've got the whole concept totally wrong.
Either that or it worries me I do something horribly wrong and somehow other people program the way you see in those typical 'computer hacking' programming type things you see in movies.
A text editor but with "record" and "stop" buttons. Click "record", write all your code, then click "stop". Now you can go back in time and play it all from the beginning, and you can also select certain stopping points as frames.
Then in your live demo, just navigate from one frame to the next, and everyone can watch the pre-recorded code being typed as if it were being done in real time.
Bam. Problem solved.
But then afterwards he told us that he had written a tool that typed out something prewritten as he mashed the keyboard.
That later turned into
Take the time to build a proper, edited presentation.
Somewhere he explained that he made a custom tool to make and play back a "perfect recording" of his edits.
2. Vim has Mundo and Emacs has undo-tree which allow you to step backwards-and-forwards through your changes.
As I see it, adding explicitly-selected frames to any of these features should be possible.
Note that I don't know how well it would work for long sessions. Theoretically it would be fine, but the way it uses ImageMagick to convert the frames to an animation can be heavy on memory, so that could be a problem. However, the frames could be stitched together with other software that didn't present that problem...
1. git checkout -b demo
2. write some code and/or comments
3. git commit -am "message of what we did in this step"
4. Go to step 2 if not finished with demo.
5. Cycle through commits with script, each one a frame.
Even simpler, a key logger with some control, wouldn't even need integration into a specific editor.
Edit, I see you can manually update stuff.
However, I can use it like this:
script --command='vim code.py' --timing=typescript.timing typescript
scriptreplay -t typescript.timing -s typescript
I'm sure the Gettysburg Address was riveting when originally given. That does not mean I enjoy every speech I hear. Quite the contrary, the exception proves the rule.
- you can see the thinking process progressing in a certain order. I know it helps me understand it, because I can see something unfold piece by piece instead of being dumped as a big fat pile of info. But also because things have a relationship, and decisions have a cause, which a good live demo will highlight.
- I can see the person interract with tooling. I like tooling.
- it gives me a sense of the time and energy necessary to put the code in motion. Yes I know the person knows the damn thing by heart, but I take it in consideration. If you use slides, or pre-made scripst, I can't even make an approximations of the time it takes to get there, because I'm missing tons of steps, outputs and links.
- it's reassuring. The thing doesn't seems so abstract anymore, as you can see it coming to life, instead of "in theory, it works like this". It makes me want to try the thing.
- it's easy to follow. A lot of coders suck at making presentations that lead me from their A to their Z, and I have to adapt to every style, every slide, etc. But most coders on stage know how to code, and I understand their process. It's like peaking into the box to see the product instead of reading the packaging. Plus, so many speakers suck, either because they are too shy, or try to be too much. But live coding is just natural to me.
Now, I don't always live code during conferences. Sometime I use slides, sometime I use scripts, sometime I code, and often I mix and match, with hand drawing, pictures, schemas and every tool I get. I also speak, stand alone, about something unrelated to the computer screen, to maintain attention and create a more personnal interraction.
But those are hard to do for most people, not trained to speak in public, not used to explain their though process or understand how people will interpret it. It's a skill that needs a lot of practice. And not everybody will get such practice before their conf. Live coding can help with this, as it's a nice compromise.
I have never been bored in these talks!
According to audience feedback I've collected, my talks where I do a lot of live coding are engaging and fun. But that's cos I practice, and I put effort into the talk.
The key to a good presentation is to polish it and engage the audience. It's part teaching and part performance, and if you don't do both of those well, you'll lose people. Ask the audience questions to get them involved at key places. Practice so you know the timing of things.
If you just show slides or just live code, you're probably better off recording a youtube video, tweeting it out, and spend conferences enjoying the hallway track. :)
I had one part where I intended to livecode a hello world app for threeJS. The whole code was printed in my hand, so I read it through and typed it out. 3 minutes later, it didn't compile and I could tell my audience was getting bored, so I bailed and showed the end result.
At the end of it, I was told it was one of the better talks given at my local meetups and it was more like 3 talks in one. So that was a huge compliment. I didn't catch anyone falling asleep or leaving either, so that's a good sign. I kept it engaging by asking a question every 10-15minutes to test if my audience knew anything about the topic, at the 20% 40% 60% 80% and 100% points of the talk. I tried to tailor analogies based off things my audience would know, or the responses I got during q/a.
This past weekend I went to a google cloud conference and watched a dozen presentations. Some were good and informative, others way too slow-paced and/or hard to read on screen. Quality varied greatly. None of the presenters asked questions during talk. I feel like there was a missed oppurtunity here
I personally think the 80/20 rule applies here - 80% slides, 20% livecoding + asking questions to the audience. It's boring listening to one person talk the entire time, no matter how engaging they might be. The best presenters takes feedback from the audience straight into code. Those are always fun.
As a side note, the livecoding should really happen somewhere halfway during the presentation. Ideally, everything should be recorded on video anyhow as a backup.
I think it's also important to know your environment as well. I have a natural tendency to want to walk around if possible while presenting, because standing still is boring for the audience. Sometimes, the projector is incredibly hard to read due to poor lightning as well. So it's important to consider what color your slides are going to be. Font sizes, transitions, content per slide, opacity for highlighted code sections, etc should also be considered. Pure black backgrounds aren't that great, personally a linear-gradient darkgrey is more inviting. Important transition points should use a different slide color.
Lastly, bringing tools with you the day of talk. Laser pointer, extension pole, pointing to the slides, your phone + notes linked to slides.com, hardware for recording, tripod, lapel mic, camera, backup chargers, a mouse, downloaded slide assets for offline viewing, ready to show-code on vscode, memorized shortcut keys and/or extensions to show what keys are pressed, printed notes, etc. There's a surprisingly huge checklist of items you should have available as a presenter, at least if you treat it seriously.
I wrote a post about my first talk and things I wish I did right. https://vincentntang.com/things-wish-knew-first-tech-talk/
I would also love to see better tooling made for creating presentations from code. I usually end up painstakingly custom highlighting code so that it can be stepped through line-by-line on slides which is very ungrateful and frustrating work. I also haven't done this in a while, so if folks have found or made tools that make this easier, please send me recommendations!
-Presentation rendered made from Rmarkdown shared with evertone, so they can copy paste from it and run it on the Console as I take them through the slides
- The source Rmd used was also nice along with the entire data, which means the chunks of R code in the presentation is available within Rstudio so they just have to click the run button at each section and get the output
There was some live coding but predominantly it was the existing prepared code edit and rerunning. It worked!
Presentation for reference : https://amrrs.github.io/r_beginners_workshop/presentation.ht...
OpenGL programming, simple FPS style walking scene (DOS, 256 colors, dithering, OSMesa): https://youtu.be/vkUwT9U1GzA
Creating a MicroBlaze emulator in C++11 (runs Linux!): https://www.youtube.com/watch?v=1e0OCwlaEZM
Tandy 1000 Soundchip revisited: ASM programming example: https://www.youtube.com/watch?v=gjuHxjdv3ZE
Creating a DCPU-16 emulator in C++11 [here Bisqwit also gives oral explanations]: https://www.youtube.com/watch?v=MvDtr3cNaLU
I just felt really old...
Unless the context is a coding lesson, though, I agree that live coding is unnecessary and somewhat stressful to watch. It's like watching someone swallow a sword, I don't want to see it go poorly.
Most of the time there is this tension in the audience as you see the poor person make a small typo and you wait the longest, hoping they will notice it themselves, then they try to run it and they can't figure it out and you sit there trying to explain it and they are stressed out of their mind and can't understand what you are saying because they are reading a different file in the ide than the one you are referring to and aaaaaaaahhh.... the authors pain is real.
I'd really love to do another series, but I don't really like the idea of "And oh, BTW, here's one we prepared earlier". However, it seems to be what people want to watch (including myself!)
The other thing that I find a bit ironic is that I really want to share programming with people. I love it. However, I'm really embarrassed about my programming. It's never good enough -- and that's one of the things that I think makes me a better programmer. But it's one thing to share your code with yourself or your team and laugh about the stupid things you do. It's another to show it to the world. Even now, I'm loathe to share links to my series (though Google will help you find "One Pomodoro A Day" if you really want to find it ;-) ). It's like, "And now everybody will know that I'm a goof and I forget basic syntax and I look up basic library calls in the documentation and I make mistakes with TDD all the time and my design is sometimes really naive and..." well, you get the point. It's terrifying! But compelling at the same time.
I've always identified with being an artist and I think programming really is a performance art. I usually don't care what I program on -- it's the programming that matters to me. The fact that I often suck is disappointing, but I'm always thinking, "What's the point of writing this if nobody will ever read it"? I wonder if other people feel the same way...
It's a lot of work but it comes out looking effortless, and without wasting any of the audience's time.
I think a great deal of the actual "typing time" isn't necessary, but showing the intermediate steps usually is. I think the authors show it just as a means of avoiding the very time consuming process of editing a video. So there's some give and take. They save a considerable amount of their time that would have been an incredibly boring and time consuming process, and you loose a little bit of your time but get to watch a video that wouldn't have been made otherwise.
If anyone cares to see my example (as-in, in my opinion) of one of the best session we did recently, skim this 1-hour Connect(); 2018 Scott Hanselman keynote and I would honestly love to hear what you think of the approach we took.
>> I can think faster than you can type
No, you can't. Just because the author operates at XYZ skill level, does not mean the rest of us are similarly impaired. I'm sorry he had to sit through so many boring coding presentations that he purposefully chose to attend.
Most of us can read and understand code faster than we can type it out.
It just has near empty overlap with devs?