Writing code doesn't mix well with oration
inconshreveable.com
inconshreveable.com
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.
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.
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.
>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.
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.
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 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...
His presentation is web-based, so his live coding interacts with his "slide-ware", e.g. changing slides is accomplished by setting application state.
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.
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.
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?
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.
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.
Original title: "Your live coding demo is boring"
Current title: "Writing code doesn't mix well with oration"
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...
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
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.
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 :
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.
Plan before you present.
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?"
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.
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. ;)
This is how to do it correctly: https://youtu.be/O2XG846oKAY?t=211
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.
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.
... But if it was mostly copy & paste from a completed project, then it would be very well put together!
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
Just curious.
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.