Hacker News new | past | comments | ask | show | jobs | submit login
Writing code doesn't mix well with oration (inconshreveable.com)
173 points by jf on Nov 13, 2015 | hide | past | favorite | 88 comments

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.

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.

> I was in a small circle on the floor of people who had just smoked some amazing herb before the talk.

This is a thing at software conferences?

I think it's a thing anywhere people gather, no? It's probably more a thing at community conferences than corporate conferences.

Did you stand in the designated smoking area?

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.

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!

Similarly, I really enjoyed Raymond Hettinger's 2015 PyCon talk, which also had a fair amount of live coding.


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.

Yep, there are certainly exceptions! It's not a blanket rule. Rants aren't quite as much fun if you equivocate for the 5% case though. =)

> 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.

Although not a "true" live coding demo in the normal sense, but this talk won't have nearly the same effect if done via video instead.


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.

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 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.

Thanks for the video, looks interesting.

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.

Good analogy! Perhaps judicious use of libraries is like those little bowls full of chopped and measured ingredients.

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.

I think OP addresses that concern:

>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.

Well, there is some ambiguity here.

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 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.

I don't really agree with this. There are certainly some really bad ways to give live code demos, but I find that when its done well it can be very effective. I feel like the small delays and the slower buildup of code can give me in the audience time to understand and follow along.

It makes me think of my college math classes, I always preferred the professors who would work through the problems by hand on the board during lecture because you could easily follow along through the whole process. I had some professors who used examples prepared ahead of time either on powerpoint or overhead projection, even though the same steps were there, it was harder to follow. I found it more difficult to learn from the prepared demos because it was easier to get overwhelmed, you went from 0 to a lot of content instead of slowly building over time, additionally the professor tended to move a little more quickly than they would have otherwise.

I also think live-demos can be potentially more interactive. Obviously it depends on the situation, but I've seen demos where the audience starts asking questions and its very effective when the presenter can respond with, "let's try that".

I disagree with the idea that live coding demos are universally bad. In cases where they are practiced and calculated, they actually convert better than slides. I don't have any hard numbers on hand to back that up, but I worked as a developer evangelist for SendGrid for a couple years and I've probably spent too much time thinking about and attending Hackathons, so I feel ok speaking from experience. At any given Hackathon getting 10% of teams to use your product or API is impressive. Whenever someone has a polished live code, interactive demo I can assume it'll easily hit that mark. Being able to demo you API live in 5 minutes is a pretty strong guarantee that it'll be easy enough to implement during the weekend. Plus, developers love to see code and understand how other developers think!

I wrote about how to give a great API demo a few years ago. Points are still true, worth a read if you're thinking about live coding: http://theycallmeswift.com/2013/02/01/the-elements-of-a-grea...

Dan Abramov's talk on Redux and hot loader at ReactEurope really nails live coding for maximum effect: https://www.youtube.com/watch?v=xsSnOQynTHs

His presentation is web-based, so his live coding interacts with his "slide-ware", e.g. changing slides is accomplished by setting application state.

I was going to mention this same presentation, but you beat me to it. He does a wonderful job with the code, as well and keeping the material interesting, and he has a good sense of humor. I'm looking forward to the videos he's working on for Egghead.io.

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.

[0] http://doitlive.readthedocs.org/en/latest/

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.

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.

Any talk or presentation can be boring if the presenter or the content is boring. It has nothing to do with the medium whether it is coding, bulleted slides, or funny cat picture memes. The OP may have seen some bad presentations, but that doesn't mean there can't be good ones.

For example, look at any talk that Kelsey Hightower (ex-CoreOS, now Google) has done lately on Kubernetes, CoreOS, or Golang. He mixes in live demos, coding, CLI, and even live video game playing along with a small handful of slides. His talks are great and engaging and you walk away excited about his topic. That's because he's a great speaker and passionate about the topics he talks about. It has nothing to do with the medium.

Ex: https://www.youtube.com/watch?v=pozC9rBvAIs

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?

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.

1. https://www.youtube.com/watch?v=FITJMJjASUs

I came here just to say the same thing. I loved Jim's presentation and have watched it several times.

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.)

Wow, never thought I'd see slowbeef referred to as a YouTuber.

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.

It really depends. Some seminal live coding has introduced for me new programming techniques in a really impactful way. I needed the programmer to talk through and introduce the techniques as they worked slowly because I needed time for what he was saying to pass the BS filter and otherwise ring positive bells in my head.

The most recent instance of this for me was a talk on TDD that featured testing, of all things, CSS! My eyes were opened and I am now trying to test-drive my CSS with the tools/techniques described.


There are some funny moments at the beginning and a good agile intro overall, but the CSS TDD part starts at around 21:00 if you are interested in that.

No mention of Jupyter notebooks? By re-playing previously-typed code in notebooks, shouldn't that give the audience a REPL-type experience without waiting for the person to type? Like having your cake and eating it too.

Why was the title changed? The original title was both less pretentious and more accurate.

Original title: "Your live coding demo is boring"

Current title: "Writing code doesn't mix well with oration"

I had to upvote this even though I've done my share of live coding presentations. It hits very close to home.

How many people have to watch me misspell printf? 50? I think they know what I'm getting at.

Something else that bores the living shit out of me? Those videos where you watch people code. Oh my god. It's like watching paint peel.

Now, having trashed the concept, I'm going to keep doing it. I did this "Code along with me on an app" last year and got several emails that folks found it helpful.

What to make of the fact that I find it boring yet continue to do it? My feeling is that a presentation that's lively and informative to me isn't necessarily a presentation that has impact with the people watching it.

Last month I wanted to do a demonstration of how to split user stories in a backlog[1] -- but not just the high-level crap you get in class. I wanted to show the whole thing from concept to code.

So I did what the author suggested. I did some screen shots of code that I then walked through at the appropriate points. I was able to create an hour of video instead of dozens of hours the other way. And I think it had the same impact.

[1] http://tiny-giant-books.com/blog/technical-story-slicing-1-o...

There are tons of talks where there is live-coding but it's not boring at all. But it would get hard to get by when the guy writes more than 10 characters. The it's just messy and time-consuming.

The "video suggestion" in the text is a good way to get around this and display an awesome feature without wasting time and any eye-rollings. Also you can only give a link if the code is too complex or too much to display it your slides.

Thanks for your consideration! :D

I guess I'm in the minority in actually agreeing with the original post. I like when talks include code examples but hate it when a presenter brings up an empty SublimeText window and starts typing away. Just have it already written, show me briefly, and move on. I can understand your code snippet faster than you can type it, unless it's horribly written or your talk up to that point has not explained things properly.

Which is not to say there are zero presentations that are based on live coding that are good. There may even be a few. But my experience has been most presentations that are based around live coding are terrible.

I've seen presentations that include live coding that are good, but these presentations are actually well thought out and complete, and the live coding is only a small element, and the presenter has pre-created examples that the are basically "filling in the blanks" on.

Most presenters, though, I think would be well served to stick with the standard "show a snippet on a slide" method.

"Your live coding demo is boring"

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 :


Everything is boring if you do it wrong. For example, Jeff Lawson (Twilio CEO) is well-loved for always live-coding in his talks.


If you have never attended a presentation that includes a live coding session, one might find parallels in improv comedy.

Not all rehearsed comics, who assemble written jokes beforehand, and tell them as part of a routine, can be nearly as entertaining during an improv show. Watching a UCB or ComedySportz or Second City live show, or Whose Line Is it Anyway is very different from watching an episode of The Daily Show or Saturday Night Live.

While good improv comedians can usually do rehearsed shows, it is much harder to go the other way around. So unless you do a lot of live coding--perhaps you teach a university class that requires it--you probably shouldn't inflict it upon a big audience until after you know you can do it without boring everyone to death.

Bret Victor's talks are a counter example to this. His live programming in this[1] talk is nothing short of mind blowing.

[1] https://www.youtube.com/watch?v=EGqwXt90ZqA

You can't blame long, awkward pauses and the arrival of an "impromptu debugging session" on the act of trying to code in front of an audience. That's like saying all plays suck because of the terrible actors in one that you saw.

Plan before you present.

If you think watching someone do a live coding demo is boring, you are probably not the target audience (and I would guess you may be in entirely the wrong field if you are a programmer who thinks programming is boring).

Imagine a painter saying that another painter showing a specific 'new' technique that they developed is 'boring' and they should 'just talk about painting, don't show us anything'.

I would imagine the author of this blog post is the sort of person that sat in the back of Chemistry class, and after seeing the teacher do an experiment asked "is this going to be on the test?"

In general I'm of the same mindset as you, but to be fair it's not exactly an apples to apples situation.

Painters demonstrating a new technique are far less likely to get bogged down trying to figure out why the wrong colors are coming out of their brush or why some strokes don't show any color at all, why their canvas is crashing, etc.

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. ;)

Your live coding demo is only boring if you do it wrong!

This is how to do it correctly: https://youtu.be/O2XG846oKAY?t=211

I think that live coding can serve as a really good tool if you do it right and it applies directly to what you're doing. For example, it works well in this demo https://youtu.be/Agu6jipKfYw because it's a demo of how Elm can help you think about what's going on and debug your code on the spot. This presentation would have been a lot more boring if it lacked a live demo.

Live coding is great when done well, and when the presenter is handling it well. Everyone enjoys seeing if the code will work, but no one enjoys watching someone sweat and stammer too much if things start going badly.

As a presenter I've done some live coding at times, but I've always had a clear plan for how to proceed if things don't work as I intended. We laugh together, and no real time is wasted. I enjoy watching other presenters who take a similar approach.

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.

That's not always true.

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.

While I do agree that live coding can be quite boring, it is helpful when trying to demonstrate coding conventions. Learning code from a live tutorial is far easier than from a wall of code (that can be copy pasted better from a website and such). A lot of people attend these talks to learn, and it is up to the presenter to judge what best fits of the type of presentation.

Your live coding demo is boring...

... But if it was mostly copy & paste from a completed project, then it would be very well put together!

I think the real take away is "Don't do live coding on stage unless you are already a compelling speaker". There are several example of good talks that include live coding, but they all tend to be by expert presenters who know how to keep the talk moving and have the coding be well rehearsed.

Thanks for all comments with live coding videos!

P.S. I don't know if this was really live (looks like it) "Wat by Gary Bernhardt" https://www.youtube.com/watch?v=20BySC_6HyY

Those are tiny screencasts, some as short as just a few frames, embedded in a Keynote file. I re-recorded some of them several times in my hotel room that afternoon to make sure that there weren't distracting typos. I can't get to that level of polish when doing it truly live, but with enough practice runs I can get close enough that no one is ever waiting for me.

Still great demo! Thanks for wonderful talk!

Not being cynical, but I think it's more of I don't have the attention span to follow your demo and that's why it bores me. Demos tend to move at a slower pace than what an average programmer goes through on their own so they probably run out of patience.

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.

I feel like Gary Bernhardt gets live coding demos right, both with his DAS casts, and his conference talks.


Thanks. It takes a lot of effort to make live coding that smooth. The initial practice run of a 12-minute screencast was often 30-60 minutes, which would be boring and usually contain less information than the shorter final version. That difference came mostly from sinking effort into it: continuous simplification of examples, explanation, and even wording; and practicing until I (as the speaker) found myself engaged the whole time, with no spots where my attention dipped significantly.

I've always liked the way that Apple's WWDC videos have approached this issue. They show the code being entered, but it comes in by way of preset snippets, so they can add the code and discuss it one block at a time.

That's why I implemented (an early personal version of) doitlive:


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 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.

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.

I've also seen some people put their demo's on github and then later on the people can follow along on their commits. I think that works pretty well

Even this one? https://vimeo.com/105955605 :)

I mostly agree, I would rather have you walk me through a proof of correctness than watch you code something.

here is a great live coding demo that explains the y combinator from first principles


i really love http://neckbeardrepublic.com awesome stuff by @myusuf3

Did you see APL live coding on stage?

Just curious.

I haven't, any particular video you have in mind?

We do it for the adrenaline rush

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.

> but that's because it was novel (her sex provided that)

I'm hoping I misunderstood this. If not it is one of the more sexist things I've seen on HN.

Number one, even though we're talking Hacker News, it's still the Internet. Is this your first day?

Number two, there is nothing sexist about what I've said.

Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact