
Your live coding demo is boring me (2015) - pizza
https://inconshreveable.com/11-13-2015/your-live-coding-demo-is-boring/
======
shortj
There are a lot of caveats, good live coding demos seem share some of the same
properties:

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

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

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

~~~
cschmittiey
You wouldn't happen to have a link, would you?

~~~
vntok
[https://www.youtube.com/watch?v=rhN35bGvM8c](https://www.youtube.com/watch?v=rhN35bGvM8c)

Start around the 8 min mark

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

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

~~~
jordigh
Hi is me:

[https://www.youtube.com/watch?v=NSLvERZQSok#t=965](https://www.youtube.com/watch?v=NSLvERZQSok#t=965)

That later turned into

[http://doitlive.readthedocs.org/en/latest/](http://doitlive.readthedocs.org/en/latest/)

and

[https://www.youtube.com/watch?v=u4_UhFloISY](https://www.youtube.com/watch?v=u4_UhFloISY)

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

~~~
jordigh
Ah, probably using playerpiano. Same idea, but I wanted it for bash.

~~~
orblivion
Ah, yes, and in fact the presentation was from Pete Fein himself! I guess he
did release it after all.

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

~~~
mikestew
_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.

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

------
tacon
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](https://www.youtube.com/watch?v=kG2SEcl1aMM)

I have never been bored in these talks!

~~~
w4tson
+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

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

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

~~~
Kagerjay
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/](https://vincentntang.com/things-wish-knew-first-tech-talk/)

------
inconshreveable
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!

------
amrrs
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...](https://amrrs.github.io/r_beginners_workshop/presentation.html#1)

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

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

------
wolfgke
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](https://youtu.be/vkUwT9U1GzA)

Creating a MicroBlaze emulator in C++11 (runs Linux!):
[https://www.youtube.com/watch?v=1e0OCwlaEZM](https://www.youtube.com/watch?v=1e0OCwlaEZM)

Tandy 1000 Soundchip revisited: ASM programming example:
[https://www.youtube.com/watch?v=gjuHxjdv3ZE](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](https://www.youtube.com/watch?v=MvDtr3cNaLU)

------
hkon
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](https://channel9.msdn.com/Events/MIX/MIX11/FRM08)

I just felt really old...

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

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

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

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

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

~~~
poidos
Have you given Spacemacs a try? I've been using it for about a week now and
it's pretty revelatory.

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

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

------
LyalinDotCom
[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](https://www.youtube.com/watch?v=5_iE7azx7Vo)

------
ceocoder
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](https://youtu.be/HgWHeT_OwHc?t=7159)

[1]
[https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat)

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

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

------
chooseaname
Unless you're David Beazley.

~~~
er0k
exactly.
[https://www.youtube.com/watch?v=MCs5OvhV9S4](https://www.youtube.com/watch?v=MCs5OvhV9S4)

------
Psyonic
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](https://youtu.be/mARO-qchsKM?t=2386)

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

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

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

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

------
Nalta
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!"

------
edhowzerblack
The flaws of live coding demos apply to remote code-pairing challenges as
well, which is why I hate them with a passion.

------
ohiovr
The original docker demo was impressive to me in that it demonstrated how fast
it was to spin up containers.

------
hartator
I like seeing code being ran live though, even if the change is a couple of
characters.

------
Haga
There is a audience for live coding? Search at twitch?

It just has near empty overlap with devs?

