Your live coding demo is boring me (2015)(inconshreveable.com)
inconshreveable.com
Your live coding demo is boring me (2015)
https://inconshreveable.com/11-13-2015/your-live-coding-demo-is-boring/
90 comments
I feel like the best way to do a live coding demo is to compromise on either the live or the coding part. For example, by preparing the code ahead of time, or playing a prerecorded video of instead. This convinces me that live coding is an inherently flawed concept.
Live Coding is like a Cooking Show, and should use the same tricks. Prep everything in advance, and then show it off live, and demo little snippets, but not the whole process with all the long and boring parts.
The only live coding I have seen that was interesting was Notch working on a new game a few years ago. It was interesting because "debugging" was looking at what was rendered in the game and changing it. The experience for him was as visual as it was for us instead of inside his head.
You wouldn't happen to have a link, would you?
https://www.youtube.com/watch?v=rhN35bGvM8c
Start around the 8 min mark
Start around the 8 min mark
I can't speak from experience because I've never watched a live coding before but I've never understood how it could work. I feel like a lot of what I do while I code would be boring to watch even if you program yourself.
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.
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.
Thanks for writing this. You're not alone!
I don’t mind watching the WWDC sessions by Apple, they do ‘live coding’ but it’s just pasting snippets into place with about 0% chance of it not working.
Someone steal my idea:
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.
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.
I once saw a presentation that used a Python shell. The guy typed _super_ fast and didn't make any mistakes. It was pretty impressive.
But then afterwards he told us that he had written a tool that typed out something prewritten as he mashed the keyboard.
But then afterwards he told us that he had written a tool that typed out something prewritten as he mashed the keyboard.
Hi is me:
https://www.youtube.com/watch?v=NSLvERZQSok#t=965
That later turned into
http://doitlive.readthedocs.org/en/latest/
and
https://www.youtube.com/watch?v=u4_UhFloISY
https://www.youtube.com/watch?v=NSLvERZQSok#t=965
That later turned into
http://doitlive.readthedocs.org/en/latest/
and
https://www.youtube.com/watch?v=u4_UhFloISY
Very cool, though what I saw was someone else, probably over a decade ago, who must have had the same idea independently. Though I don't know that he released it as you did.
Perhaps you're thinking of Pete Fein's lightning talk at PyCon 2019 in Atlanta?
https://www.youtube.com/watch?v=MVzTcQkMNXg
https://www.youtube.com/watch?v=MVzTcQkMNXg
You should post a show HN of this. It's really cool and I definitely will be using this in about a month. I wouldn't have found it if not for this comment.
I didn't make it. I made a quick personal hack a few minutes before my lightning talk and Steven Loria later turned it into a real package. I'm just listed in the kudos:
https://doitlive.readthedocs.io/en/latest/kudos.html
https://doitlive.readthedocs.io/en/latest/kudos.html
this is awesome! nice work
Http://hackertyper.net does that for silly Hacker text, or http://geektyper.com/mobile/ for mobile.
There's something similar for PowerShell: https://www.powershellgallery.com/packages/Start-Demo/1.0.1
Please no. That's the equivalent of presenting an unedited video recording onstage and saying it's all cool because you can fast forward and pause it.
Take the time to build a proper, edited presentation.
Take the time to build a proper, edited presentation.
This is more-or-less the format Bisquit uses in his tutorial videos, e.g.
https://youtu.be/vkUwT9U1GzA
Somewhere he explained that he made a custom tool to make and play back a "perfect recording" of his edits.
https://youtu.be/vkUwT9U1GzA
Somewhere he explained that he made a custom tool to make and play back a "perfect recording" of his edits.
I love how epic the music is
1. asciinema[0] has the ability to record a terminal (and thus, terminal-based editors) and replay it. By default, the replay comes with pause (via <SPACE>) and play-single-frame (via <.>).
2. Vim has Mundo[1] and Emacs has undo-tree[2] 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.
0: https://asciinema.org
1: https://simnalamburt.github.io/vim-mundo/
2: https://www.emacswiki.org/emacs/UndoTree
2. Vim has Mundo[1] and Emacs has undo-tree[2] 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.
0: https://asciinema.org
1: https://simnalamburt.github.io/vim-mundo/
2: https://www.emacswiki.org/emacs/UndoTree
There's a vscode extension that does exactly this. Haven't tested it, but it looks like it should work for live coding presentations.
https://marketplace.visualstudio.com/items?itemName=jevakall...
https://marketplace.visualstudio.com/items?itemName=jevakall...
Here's a demo of that in action.
https://youtu.be/rO8-cgtkZSw?t=295
The emacs-gif-screencast package does this very well. Each keystroke (technically, each command) is recorded as a frame, with timestamps used to set the appropriate duration of each frame. e.g. if you stare at the screen for 30 seconds, no additional frames are captured, and that frame lasts 30 seconds (which you can then edit the duration of later in other software).
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...
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...
Haha neat idea :) Can't you simulate this in git?
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.
Ah yeah, that would do the same thing basically.
asciinema does that for the terminal: https://asciinema.org/
You know what's funny to me is Mr. Robot does their scenes in.... flash. Even their mobile phone shots are done via flash.
that's incredible. I didn't even know that Adobe was still maintaining and releasing new versions of Flash.
They call it “Animate” now. Once they got their HTML exporter working they changed the name.
Open vim, type code. Done. Hold `u` for playing backwards, or `Ctrl-r` for playing forwards. If you want to show your undos too, then remap `g-` and `g+` to something you can hold and use those instead. If you want to save that undo history, set options `undofile` and `undodir` and perhaps `undolevels` if 1000 is too little.
[deleted]
Sounds like a cool VIM plugin to write, basically just a key logger that when ran against a file recreates what was done.
Even simpler, a key logger with some control, wouldn't even need integration into a specific editor.
Even simpler, a key logger with some control, wouldn't even need integration into a specific editor.
heres a weekend script I wrote as a prank. it just remaps your a-z keys and reads in from a renamed version of a file.
https://github.com/mjbrownie/hackertyper.vim
https://github.com/mjbrownie/hackertyper.vim
Wouldn't that just be watching you type the mistakes again, but this time without the cursing?
Edit, I see you can manually update stuff.
Edit, I see you can manually update stuff.
This app works pretty well.
I turn it on during hackathons etc, to show work done.
http://getscreenninja.com
http://getscreenninja.com
And don't record Ctrl+X and DEL and it's going to be more interesting. And mute that nerdy vocal frier. :)
scrimba.com comes to mind
Came here to say this, Scrimba is a thing and it's very well done. I just took a look, and it seems like their original premise didn't really take hold-- they're mostly pushing tutorials now, which is probably the most common use case.
I thought they were primarily for tutorials. What was their original premise? Do you mean the whole "use our framework instead of react" thing?
You could probably do something like that using vim macros.
script -r
script -pWhich version of script are you using? Mine replies to script --version with "script from util-linux 2.31.1". It doesn't support those flags.
However, I can use it like this:
However, I can use it like this:
script --command='vim code.py' --timing=typescript.timing typescript
scriptreplay -t typescript.timing -s typescriptI'm on a Mac running High Sierra at the moment.
Counterpoint, there are also some great things about live demos:
- 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.
- 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.
Sure, a live coding talk without preparation is gonna get people to check out. But honestly, if you throw up 45 minutes of slides you're gonna put an audience to sleep too.
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. :)
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 just finished my first talk. I had not prepared half the slides necessary the day of, nor practiced anything but the intro. I thought it would take 45 minutes but I went over to 1hr30mins. Only 10 mins of that went into livecoding, which I rehearsed a dozen times.
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 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/
Author here. After four years, I still stand by this advice/critique. As everyone likes to point out, there are a few presenters that are an exception to the rule. That's true! I'm certainly not one of them, though.
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!
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!
Counterexample of a non-boring "live" coding demo (OK, it is recorded and played in a faster tempo): Some of Bisqwit's videos. Some of my favorites:
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
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 once did a live coding series about learning a new language (Elm in this case) where I tried to show how to apply general knowledge of programming into learning a new language. I edited it heavily. It was still horrible :-) I quit after 5 episodes, I think. I also did a series (about 60) of Ruby TDD (which I called "One Pomodoro a Day") where I did one single pomodoro every day, unedited and recorded it with Asciinema (no audio). For me, this worked pretty well and I think it's quite watchable at 2-4x speed. However, it's still me fumbling about in my normal "Oh heck, that was a stupid idea, let's try X" way. I've shown it to a few people and it never got any traction, so I shelved it.
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...
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 takes longer, but the best presentation of this kind that I've given was from taking video of a live coding exercise and editing it extensively (removing typos, adjusting speed). Then split it into sections and made a sequence of short clips out of them. Then put that into a presentation with one clip per slide. That way if I was a little slower when talking than planned, the video wouldn't get ahead of me, it would reach the end of the current clip and advance once I brought up the next slide.
It's a lot of work but it comes out looking effortless, and without wasting any of the audience's time.
It's a lot of work but it comes out looking effortless, and without wasting any of the audience's time.
I've enjoyed a lot of emacs presentations on YouTube where they're doing it all live and talking through it. Often it teaches me something new and makes me want to use emacs more. (I still mostly use vim)
Have you given Spacemacs a try? I've been using it for about a week now and it's pretty revelatory.
[Disclaimer - I work at Microsoft and have worked on developers events for many years] now with that said, I have seen both some amazing sessions, and some terrible ones. Live coding alone is typically not the single biggest problem, but an important element of the bigger picture. Simply put, a great presentation is certainly not easy and involves balancing many things.
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.
https://www.youtube.com/watch?v=5_iE7azx7Vo
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.
https://www.youtube.com/watch?v=5_iE7azx7Vo
I generally agree, but there are definitely exceptions. The most impressive I've seen is Haoyi Li parsing a decent chunk of Haskell using his FastParse library in ~10 minutes: https://youtu.be/mARO-qchsKM?t=2386
There is nothing worse than watching a live debugging session. On the flipside, DeepMind did a great job with their StarCraft presentation yesterday, showing pre-recorded commentary/analysis as well as select highlights. These types of talks (with animations, etc.) should definitely supplant live coding.
From TFA
>> 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.
>> 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.
So... you're saying that you're some god-level typist and logician who can push out multiple 500 character Python 1-liners in 2 seconds or ... something?
Most of us can read and understand code faster than we can type it out.
Most of us can read and understand code faster than we can type it out.
No I'm an ordinary professional. I don't start typing until I've thought it out, and then it's a very mediocre 100-115wpm. I'm saying the article author must be an exceptionally slow typist, or prone to mistakes - not that I am anything more than average.
The flaws of live coding demos apply to remote code-pairing challenges as well, which is why I hate them with a passion.
The original docker demo was impressive to me in that it demonstrated how fast it was to spin up containers.
There is a audience for live coding? Search at twitch?
It just has near empty overlap with devs?
It just has near empty overlap with devs?
I have watched a couple (out of hundreds) of magical coding demos, one that comes to mind was Steven Sanderson demo of Knockout.js
https://channel9.msdn.com/Events/MIX/MIX11/FRM08
I just felt really old...
https://channel9.msdn.com/Events/MIX/MIX11/FRM08
I just felt really old...
I have had some amazing learning experiences from watching someone live code. When the intention is to show people how to actually go about the act of coding itself then it makes sense to do so with a live demo. In the cases that worked for me the live coding was very much a performance; a scripted lecture that combined theory and implementation with a little room for questions.
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.
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.
Imo the author isn't saying that live coding talks can't be high-quality or even 'magical' - just pointing out that the practice is more likely to detract from a presentation than improve it.
No I guess I meant to say out of hundreds of live coding talks, a couple were very good.
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.
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'm not sure I agree with this post. The now-legendary "Build a blog in rails in 30 minutes" thing was one of those "holy crap" experiences for me. Seeing how, start-to-finish, you could have a fully functioning blog with authentication and everything was sort of magical, and I don't think having a slide showing Rails commands would have been as interesting.
The now-legendary "Build a blog in rails in 30 minutes"
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.
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.
[deleted]
I agree. Especially in sessions focused on the process of writing code, such as the original Rails demo, I find live coding to be very engaging.
As usual leave it up to Jeff Dean to be an outlier, this[0] is his talk/demo at GCP Next 2016 - I was on edge of my seat as I watched him talk and code things up at the same time. He is awesome. Oh and Gary Bernhardt's talk WAT[1] which happens to be one of my favorite talk of all time.
[0] https://youtu.be/HgWHeT_OwHc?t=7159
[1] https://www.destroyallsoftware.com/talks/wat
[0] https://youtu.be/HgWHeT_OwHc?t=7159
[1] https://www.destroyallsoftware.com/talks/wat
I’m as much a Jeff Dean fan as the next guy, but he doesn’t live-code in the talk you linked. The article says code/demo is great, just live-coding isn’t.
If you're just going to show a video, why not skip the whole presentation and just make a video? The whole point of a presentation is to be able to read the room, slow down or clarify points, and to respond to feedback in real time.
I feel like the biggest criticism here is that live-coding in presentations tend to be unrehearsed. That can be fixed by rehearsing it and shaking out the bugs ahead-of-time, thus avoiding the "impromptu debugging session".
Totally agree that it needs to be well-rehearsed. An alternative to being super well rehearsed is to record a video of the live coding and talk live over that, a technique I've used successfully in the past.
This was the format I followed recently for an R workshop.
-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...
-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...
More youtube tutorials should take this into account too. I really don't need to see someone type out the code. A walk-through of pre-written code is much more interesting.
It depends. Usually the code evolves in a live coding session and a lot of code is deleted or changed to show intermediate steps to make a point. Just seeing the finished product isn't the same thing.
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.
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.
I agree except for shaders and procedural generation. It's not boring then, since you look at the output at the same time. But it can be boring too if it's too repetitive.
I would go a step further. Please don't show me code. Show me runtimes, interesting problems, and MAYBE a line that shows "Aw gee! Thats easy!"
I like seeing code being ran live though, even if the change is a couple of characters.
Venkat Subramaniam has a signature presentation style built around live coding interspersed with live construction of his discussion topics inside his editor. The first recent example of this live coding style I found is
https://www.youtube.com/watch?v=kG2SEcl1aMM
I have never been bored in these talks!
https://www.youtube.com/watch?v=kG2SEcl1aMM
I have never been bored in these talks!
+1 For Venkat. I haven’t come across another speaker who can code and talk and teach all at the same time like he can. He even manages to be funny. I have a lot of love for this guy
- 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.