Exactly. Most talks are "show you something working" which is of extremely low value. That stuff is easy to pick up for most people. It's why most talks are dry and boring. You've reached the conclusion far faster than the speaker can get to it.
The real value is in the transitions. From nothing to something. From broken to working (like when Rob hit unexpected errors, the same way you would if you were tinkering for the first time). That's where I learned something in Rob's talk.
> Sitting there for an entire 50 minute watching someone code?
Yeah why go to a talk if you have to pay attention? The nerve!
You can read HN and Twitter on your phone any time you want.
- directionless
maybe I quitted too early to be enlightened but
10 minutes in I couldn't tell what was the goal/point
- unorganized
* rename, rerename
* move window, resize, re-move
- jittery typing
- (imho stupid) background music
The sounds of keystrokes is actually better..
Next time, use a tiling manager, show a minimal plan ( 4 bullets ), spare us the stadium-oriented noise, author can even gratify us with the sweet sound of human commentary, even if just a few.
The OP says: "The talk was pushed up 24 hours as another speaker missed her plane to the conference and we had to do a last minute shuffle (literally, I found this out at midnight the night before).". It WAS unorganized.
> - jittery typing
The guy was very nervous and I would make a lot of mistakes if 20 o 30 people were watching me coding.
I agree with you that is important to have a plan, objective or whatever. It's important to know what he was doing, for the guys who started seeing the "talk" and the guys who join the "talk" in the middle.
And yeah, in the beginning I just flailed with the file names. Ack! I had run through this talk 12 times - it needed 12 more run throughs.
Music... it's Daft Punk... can't please em all I suppose :)
I didn't read the backstory at the time of my comment, I apologize for that.