Live code demonstrations with the important stuff live coded (maybe a line or two), and the other stuff skipped with incremental git tag checkouts works the best, from my experience.
I actually feel and do the exact opposite. I find code on slides to be boring. When I present I want to give the audience an experience like they will have. Live coding can do that well. But it certainly can go bad quick. Live coding on stage takes a TON of practice. Most presenters don't put in the prep so it comes out boring and fail-prone.
Probably the most important thing I've learned in 10 years of tech presentations is that every person in the audience learns in a different way and wants something different. You can't please everyone no matter what you do.
The rise of livecoding, especially with the ability to now stream any kind of programming on Twitch, should lead to a reevaluation of how to properly present coding live in an engaging manner.
Recently, YouTuber slowbeef has started streaming live ROMhacking of a Japanese ROM to translate it into English (archive of 1st stream: http://youtu.be/kCaj88nLY4o ). While this example is not explicitly coding, the emphasis on explanation shows how important presentation can be to engaging code demos.
I've been working on Twitch-streaming workflows myself for potential live code streaming. Just enabling OBS and turning on a webcam while coding is not enough to be engaging ipso facto. There needs to be some semblance of planning beforehand. (also keep in mind that any code you stream may be seen on mobile devices, so you will have to increase font size accordingly.)
One exception I can think of is the demos that I've seen for Overtone, the clojure music library. Watching music built in real time was rather interesting.
LiveCoding.tv is popular, and they're not prepared demos. They're mostly people googling their problems.
Watching a flawless live coding demo can be impressive and inspiring.
Also about "I can think faster than you can type.."... if you can reason about code in a new language or framework faster than someone can type it, you probably shouldn't be in a talk about that language or framework.
I'm shocked to see that from you. You don't have enough information to make such a claim, and it's a horrible thing to say about someone otherwise—especially when (as I tried to make clear in the thread you linked to) their health may be involved.
I'm confused why there is any shock, to be honest. I base my definition of the word on the one given in this wp article: https://en.wikipedia.org/wiki/Psychopathy Particularly, the word does imply an individual is suffering health issues, as far as i read it. I don't know how you understood what i said, so i can't usefully say if i made a mistake or you understood my intentions. Though please understand that i did not mean to denigrate, merely to explain.
Feel free to let me know if you still think it was a mistake, and i'll keep that in mind for the future.
Ah ok, this was just a misunderstanding of terminology. "Psychopath" in English has a specific meaning having to do with lack of empathy and conscience, etc.—not mental illness in general. (It's perhaps confusing because "psychopathology" is quite different from "psychopathy" and does mean mental illness in general.) Colloquially, to call someone a psychopath is to condemn them harshly—even though technically it's an illness, though not everyone believes this—while to say that they're mentally ill is more neutral and in context can be sympathetic.
Your English is either native or extremely close to native, so it didn't cross my mind at all that you didn't mean the word as an insult, especially since some HN users throw it around too freely. My apologies for lumping you in with that!
I'm reminded of that video that I believe was posted to Hacker News a while back of the young female programmer live-coding a simple Space Invaders clone in JavaScript. What she did wasn't boring, but that's because it was novel (her sex provided that), it was fun (being a game), and most importantly it was obviously well-rehearsed.
If you're going to do live-coding, you have to realize that it's far less demo than it is performance; and if it's not going to be that, do us all a favor and skip it.
I'm not sure I always agree with this. David Beazley's 2015 PyCon talk on concurrency (https://www.youtube.com/watch?v=MCs5OvhV9S4) was one of my favorite talks of the conference, and it was almost all just live coding.
Part of what made that talk compelling was that it took a concept that lots of people find complex/intimidating (how the internals of an asynchronous IO library work) and in ~30 minutes created a full working example in front of a live audience. Writing the code live in front of the audience helps to nail down the central theme of "this stuff isn't actually as scary as it looks".
There are certainly talks that would be better of just presenting snippets of code, but I think there's a time and a place for live coding examples as well.
I came here to say exactly this and link to that talk. If you can't code live then don't, Beazley apparently can. Python lends itself to these kinds of talks because of its brevity.
I came to the comments on this one just to make sure this talk got mentioned as a counterpoint. Fantastic explanation of everything as he went along.
As I recall, he actually took the same conceptual problem and rewrote the solution in a handful of different concurrent styles.
And no, at least in this video I can not think faster than Dave Beazley can type. By the time I've just about figured out what nuance of concurrency he's showing off in his last example, he's already got his next example typed out!
I agree with you, but I'm probably biased because I've used live coding in one of my talks. However, the intent of coding live was similar to the talk you mentioned - it was to show people that what I was trying to accomplish isn't as hard as people think it is. In fact, it's easy enough that I can do it in an hour while explaining out loud what's happening.
Yea I remember that one, it is a great example and awesome talk.
However as far as presenters go, this guy is a bit of an outlier. He is also a teacher, he offers some python mastery classes in Chicago, so he is more practiced at explaining and working through example code.
Agree with this. In my undergraduate, 2nd year course of Opeating Systems, one day (pretty soon after the start) the teacher decided to write a small terminal emulator in C to show us what it really does, just there, in the classroom. It took him 2 hours of coding, but it really changed my perspective on how things really work in a UNIX based system, and on always checking in depth whether something that sounds like almost impossible really is.
Being in the crowd during this talk was seriously like being at a rock concert.
Beazley was 'playing' the keyboard like an instrument. Every square inch of floor space had someone sitting or standing. The crowd was incredibly invested - nary an eye nor ear wavered. Even Guido looked on with a hawk eye.
I was in a small circle on the floor of people who had just smoked some amazing herb before the talk. I was hanging on his every word and every expression. I've rarely felt so engaged by a conference talk. I'll never forget this one.
He received a raucous standing ovation that is not evident from the conference video.
I asked a question at the end, and I was so giddy I had trouble getting it out. :-)
As a core contributor to an async framework, I felt that this talk gave me a lot more enthusiasm and confidence about my work which has lasted to this day. I think about it often. Definitely a track for the PyCon greatest hits album.
The people who really know what they are doing make the complicated stuff seem dirt simple. I had Dave as the instructor for my undergrad compilers and operating systems courses back in 2000-2001. His lectures then were every bit as enlightening as his PyCon talks today. Those courses were demanding but extremely fun.
> There are certainly talks that would be better of just presenting snippets of code, but I think there's a time and a place for live coding examples as well.
Step 1. be David Beazley. He really is such an engaging speaker and I think his jokes and lightheartedness might make it look easy, but I don't think it is. Many probably think in their heads "I'll be just like David on stage" but they are not.
I have see nice demos where everything is setup and they just run a command it builds or launches a VM, that's fine. But building code from scratch, watching it compile, dealing with 1 off errors, or some hidden bug that now everyone is debugging, is usually painful to bear through.
Living coding isn't lazy, unpracticed living coding is lazy. I find live coding to be a lot more effective than explaining code that's already there; as a speaker, you have the opportunity to explain the reasoning behind and relationships between each line of code.
>That does not mean you shouldn’t show code on stage. Please, by all means, put code up there on your slide and talk about it. Just don’t write it in real time. Live coding is lazy; it is a shortcut for creating quality presentation material. On well-prepared slides, your code will be magnified to ensure that I can read it. It will be highlighted so that you can direct my attention appropriately.
I would say that I much prefer live coding to code on slides because I can see it actually compile and run. Proof that what is said works, works. I might even get to see common gotchas. It's obviously a gigantic failure if we only see errors and never working code, but then that speaks to the nature of what is being demonstrated.
With presentations, you can show a chunk of code with a presenter confidently stating "This works!". Of course, that's no guarantee that it does, and frankly if you tried to implement what was demonstrated and it ends up not working, you would get blamed for it. "You clearly did it wrong, you were supposed to do it like this: ".
Live coding shows you all the context, because you must show all the context, and it gives you a concrete example that you can yourself run. A working hello world. It does something critically important, it takes the blame of something not working for you, off of you.
of course the ambiguity I mentioned are the golang slides, which are actually demonstrable pieces of code. With a little "run this for yourself" button on each slide. That's a really awesome solution.
I haven't had occasion to use it in anger, but I keep doitlive[0] in my back pocket for such things. 'Live' typing, but repeatable and working each time.
Well, that just records the commands, the output can still change, internet connections fail, etc. I have a tool I wrote for some internal presentations that uses the dumps from ttyrec to play back everything in response to random input.
Rather than use a single dump, this expects multiple dumps, allowing you to treat them as slides, and preventing you overrunning after each command. It also lets you rewind & replay if needed.
For the demo I did with this, I recorded figlet commands printing large bullet pointy things for the bits where I didn't want to show code, and cat'd ascii art for endpages.
The point of live coding is to show it works. Which is always nice to see! Also, for instruction, glad you are hyper smart, but I for one can't follow that fast if it's completely knew to me. Live coding demo I can usually follow better than a video.
Live coding doesn't mean a poor presentation. Thought bad live coding generally does. I don't want to see someone stumble around, but Jim Weirich's live coding of katas turned me on to a lot. Not only katas, ruby, but how he coded- refactor menus, etc. Extremely valuable.
Jim Weirich's "Y Not - Adventures in Functional Programming"[1] is perhaps the most entertaining and interesting technical talk I've ever seen. It would absolutely not be as cool or as fun without the live coding. Additionally, the incremental process by which he arrives at the conclusion makes the topic much more approachable.
Whether a demo is helpful really depends on the audience, the nature of the presentation, and what points you are trying to get across. It's just one of a number of rhetorical devices.
For example in sales presentations to C-level managers it's generally better to avoid a demo and just assert the product works and sell the benefit to the business. When selling to technical folks demos are often a critical part of the pitch to show you are for real. Videos make it look as if you either don't know the technology or are afraid to show the product in action.
This is all part of basic rhetoric. If in doubt, just ask: what would Cicero do?
I totally agree that most live coding sessions, wherever they are demos or courses or casuals youtube videos are often pretty bad. But sometimes live coding just rocks :
I do a live demo in my talks but it's mostly CLI stuff. I start a service (on the local machine, so no internet issues), and do a few simple things like curl requests. Yeah, I could have put the same commands and output on slides, but I think there's something about doing the actions in front of people that makes the process seem even more accessible. Like "hey I could do what that guy literally just did".
In fact I did this in a talk I gave just last night. If any of the audience are also HN readers, hope I didn't bore you. ;)
I see Microsoft do this all the time. And I agree - it's stupid and boring. It's time wasted. They could instead be explaining the nuances of their language and platform.
I like the jump starts Microsoft do but I agree the live coding should be replaced by explaining pre-written code snippets. No one wants to see a guy spend 10 minutes debugging code he wrote in 20 seconds.
I feel like cooking shows get this right. A lot of prep work is actually already done, but not all of it.
It's nice to see that parallel in software presentations where most of a method or main loop logic is already written out and the important bits, processing, or concepts are explained within the relevant 5-10 lines of code.
Show me some of the prep, but don't make me watch dough rise.
I agree with the authors main point, however I did see a good counterexample a few years ago when Martin Fowler did a talk about his then recently published book on refactoring. He did the talking while an assistant did the live coding to keep up with the narration. "Now lets move this behaviour into the other class": magically the video followed his instructions, paused automatically at the right places etc.
91 comments
[ 3.2 ms ] story [ 122 ms ] threadJust curious.
https://www.youtube.com/watch?v=a9xAKttWgP4
https://www.youtube.com/watch?v=DmT80OseAGs
Probably the most important thing I've learned in 10 years of tech presentations is that every person in the audience learns in a different way and wants something different. You can't please everyone no matter what you do.
Recently, YouTuber slowbeef has started streaming live ROMhacking of a Japanese ROM to translate it into English (archive of 1st stream: http://youtu.be/kCaj88nLY4o ). While this example is not explicitly coding, the emphasis on explanation shows how important presentation can be to engaging code demos.
I've been working on Twitch-streaming workflows myself for potential live code streaming. Just enabling OBS and turning on a webcam while coding is not enough to be engaging ipso facto. There needs to be some semblance of planning beforehand. (also keep in mind that any code you stream may be seen on mobile devices, so you will have to increase font size accordingly.)
I helped a bit with his work on Policenauts but we haven't kept in touch since then. Maybe I'll try to get involved in this.
LiveCoding.tv is popular, and they're not prepared demos. They're mostly people googling their problems.
Watching a flawless live coding demo can be impressive and inspiring.
Also about "I can think faster than you can type.."... if you can reason about code in a new language or framework faster than someone can type it, you probably shouldn't be in a talk about that language or framework.
There is a possibility he is / was ill. Your comment comes across as particularly mean in that light.
But even without illness it's unkind to call people psychopaths (even if they behave terribly).
You know enough about HN not to do this.
Feel free to let me know if you still think it was a mistake, and i'll keep that in mind for the future.
Your English is either native or extremely close to native, so it didn't cross my mind at all that you didn't mean the word as an insult, especially since some HN users throw it around too freely. My apologies for lumping you in with that!
And yeah, i'm fluent in english, but my native language is german. (As is my mindset, which is why some bits of HN can be a little troublesome. ;) )
If you're going to do live-coding, you have to realize that it's far less demo than it is performance; and if it's not going to be that, do us all a favor and skip it.
I'm hoping I misunderstood this. If not it is one of the more sexist things I've seen on HN.
Number two, there is nothing sexist about what I've said.
https://twitter.com/patio11/status/664298705848172544
Part of what made that talk compelling was that it took a concept that lots of people find complex/intimidating (how the internals of an asynchronous IO library work) and in ~30 minutes created a full working example in front of a live audience. Writing the code live in front of the audience helps to nail down the central theme of "this stuff isn't actually as scary as it looks".
There are certainly talks that would be better of just presenting snippets of code, but I think there's a time and a place for live coding examples as well.
As I recall, he actually took the same conceptual problem and rewrote the solution in a handful of different concurrent styles.
And no, at least in this video I can not think faster than Dave Beazley can type. By the time I've just about figured out what nuance of concurrency he's showing off in his last example, he's already got his next example typed out!
However as far as presenters go, this guy is a bit of an outlier. He is also a teacher, he offers some python mastery classes in Chicago, so he is more practiced at explaining and working through example code.
https://www.youtube.com/watch?v=wf-BqAjZb8M
https://www.destroyallsoftware.com/talks/wat
Beazley was 'playing' the keyboard like an instrument. Every square inch of floor space had someone sitting or standing. The crowd was incredibly invested - nary an eye nor ear wavered. Even Guido looked on with a hawk eye.
I was in a small circle on the floor of people who had just smoked some amazing herb before the talk. I was hanging on his every word and every expression. I've rarely felt so engaged by a conference talk. I'll never forget this one.
He received a raucous standing ovation that is not evident from the conference video.
I asked a question at the end, and I was so giddy I had trouble getting it out. :-)
As a core contributor to an async framework, I felt that this talk gave me a lot more enthusiasm and confidence about my work which has lasted to this day. I think about it often. Definitely a track for the PyCon greatest hits album.
This is a thing at software conferences?
Step 1. be David Beazley. He really is such an engaging speaker and I think his jokes and lightheartedness might make it look easy, but I don't think it is. Many probably think in their heads "I'll be just like David on stage" but they are not.
I have see nice demos where everything is setup and they just run a command it builds or launches a VM, that's fine. But building code from scratch, watching it compile, dealing with 1 off errors, or some hidden bug that now everyone is debugging, is usually painful to bear through.
>That does not mean you shouldn’t show code on stage. Please, by all means, put code up there on your slide and talk about it. Just don’t write it in real time. Live coding is lazy; it is a shortcut for creating quality presentation material. On well-prepared slides, your code will be magnified to ensure that I can read it. It will be highlighted so that you can direct my attention appropriately.
I would say that I much prefer live coding to code on slides because I can see it actually compile and run. Proof that what is said works, works. I might even get to see common gotchas. It's obviously a gigantic failure if we only see errors and never working code, but then that speaks to the nature of what is being demonstrated.
With presentations, you can show a chunk of code with a presenter confidently stating "This works!". Of course, that's no guarantee that it does, and frankly if you tried to implement what was demonstrated and it ends up not working, you would get blamed for it. "You clearly did it wrong, you were supposed to do it like this: ".
Live coding shows you all the context, because you must show all the context, and it gives you a concrete example that you can yourself run. A working hello world. It does something critically important, it takes the blame of something not working for you, off of you.
of course the ambiguity I mentioned are the golang slides, which are actually demonstrable pieces of code. With a little "run this for yourself" button on each slide. That's a really awesome solution.
[0] http://doitlive.readthedocs.org/en/latest/
Here you go: https://gist.github.com/bazzargh/a267b97a52f7a1f70c46
Rather than use a single dump, this expects multiple dumps, allowing you to treat them as slides, and preventing you overrunning after each command. It also lets you rewind & replay if needed.
For the demo I did with this, I recorded figlet commands printing large bullet pointy things for the bits where I didn't want to show code, and cat'd ascii art for endpages.
https://www.youtube.com/watch?v=WBJ3hdcM7G8
1. https://www.youtube.com/watch?v=FITJMJjASUs
For example in sales presentations to C-level managers it's generally better to avoid a demo and just assert the product works and sell the benefit to the business. When selling to technical folks demos are often a critical part of the pitch to show you are for real. Videos make it look as if you either don't know the technology or are afraid to show the product in action.
This is all part of basic rhetoric. If in doubt, just ask: what would Cicero do?
http://doitlive.readthedocs.org/en/latest/
I totally agree that most live coding sessions, wherever they are demos or courses or casuals youtube videos are often pretty bad. But sometimes live coding just rocks :
https://www.youtube.com/watch?v=FvS_DG8yIqQ
In fact I did this in a talk I gave just last night. If any of the audience are also HN readers, hope I didn't bore you. ;)
It's nice to see that parallel in software presentations where most of a method or main loop logic is already written out and the important bits, processing, or concepts are explained within the relevant 5-10 lines of code.
Show me some of the prep, but don't make me watch dough rise.
This is how to do it correctly: https://youtu.be/O2XG846oKAY?t=211