I was at this specific session. I was one of those who left early.
I honestly didn't think it worked out and most people I talked to after the session didn't think it worked either. To put it lightly: People had rather mixed impressions.
He was progressively writing Node.js-code without explaining any of it in detail. His way of illustrating what his code was doing, was by cross-referencing his Node-stuff to some Ruby-based BDD framework.
How do I connect that to Node? Do I need Ruby to run node?
It came off wrong to most people. Especially with the techo-music glaring in the background, some people thought he just wanted to show off how cool he was and brush his own ego.
Other's complained that if you could actually follow his demos, you already knew the stuff he was demoing, so what was the point? So what had you just learned?
And like he said: Some people directly told him it was a waste of time.
IMO it was an interesting idea taken too far.
He makes it come off as a success, but I think that is disingenuous. This session probably disappointed more spectators than any other session on that conference. And I say that as someone who knows how good Rob can be when he's at his best.
So don't be afraid to experiment. But be prepared to see your experiments fail. Every now and then they will. Even for a guy like Rob. Especially when you take it to the extreme, like he did here.
I'm watching the video right now (got interrupted, I'm 30min in).
For me this is interesting and cool. That said, my benefits are
- I can mute the video. Seriously, the (loud, annoying) music would've been the one single reason to leave the place if I'd have been there.
- I can, of course, pause and rewind, if anything happens to fast (so far I only needed to pause it for phone calls etc)
- I actually dabbled in node (and used express) before. So while some things were new to me and really nice (I liked the mongoose intro and totally loved (ab)using the mongoose tests as a storyboard), I felt that I can follow along quite nicely.
Most certainly I wouldn't have enjoyed it on-site though. This is more the kind of 'Watch notch code' format, to be enjoyed at home.
It was Mocha with CoffeeScript, not Ruby. It actually didn't come off "wrong to most people" - it was exactly 12 who left and didn't like it. Currently it's the second most watched video from the talk, and the organizers have told me it was in the top 5 in terms of interest and people's "choice".
Ultimately, I'm sorry you didn't like it, but it's disingenuous for you to paint it as a failure.
But the point is that this wasn't clear. I thought it was neat to watch (I watched a few minutes, skipped thru) but I've used node before and write a lot of JS; if I were new to this (or if you had been, say writing Lisp or something I don't know from) it would have been very confusing. The tests thing in particular was confusing. Lesson: strings resolve to true (??).
That said I think it is a great idea to do talks more like this; I've been to talks where people go on and on about the benefits and I'm thinking "where's the beef?" But a balance would be good: x% here's how you use node y%: here's WHY you use node. The latter was missing, and the former was missing if people go slowly or get stuck on the syntax or anything.
Why does it need to be clear? That is the point - I'm challenging people to think, solve, see what's happening and digest the code - and yeah I know some people won't like it. In fact I want those people to hate it. I have a sore spot with the "entitlement crowd" who need everything wrapped up sweetly with a bow - the ones who sit on their laptops in the back of the room, geek out on Twitter, and then give your talk a low rating because it was "boring slides".
Is it hard to figure out that it's CoffeeScript? I don't think so - specifically because I said that it was CoffeeScript in the beginning. You just had to read it :).
And yes! Strings resolve to true :). Madness that people got to figure that out with some code, and not a bullet point slide!
Ultimately, I'm sorry you didn't like it, but it's disingenuous for you to paint it as a failure.
Fair enough, but I just felt like painting another picture.
If I were to offer two core criticisms of the session (as I experienced it), it would be
1. that it got sort of repetitive after a while.
2. It was a constant stream of information, a constant stream of how, without any context, or small breaks where you got explained what just happened or what we were about to do. Lots of how. No why.
Without a "why", "how" will much more quickly turn "too much how". While these are just my 2 cents, I think there is some objective lessons to be learned at the bottom of this as well.
Still. I'll give you credit for not being a cliché at the conference. You are always willing to try something new and for that I admire you.
I recall speaking at a multi-language conference in Montreal two years ago. At a speaker dinner, i ended up talking with a .NET developer who was talking about a new(ish) and awesome tool that Microsoft had developed that allowed folks to easily manage syncing whole directory trees between computers, he reported.
"Oh, that's neat, so like rsync?" I queried.
"I'm not sure I've heard of rsync." he replied.
That was the point at which I realized that the .NET and windows FOSS development world is a parallel universe that bears no resemblance nor common root to the rest of the FOSS universe.
'Oh that's neat so Puppet's kinda like Group Policy?"
"I'm not sure I've ever heard of Group Policy"
It cuts both ways. There's an infinite number of things to learn and a finite amount of minutes in a day. People that are too broad and know everything may never end up developing a deep understanding of a few things to be really productive.
There are certainly people that can straddle both worlds of *nix and Windows, but really how is a user of Microsoft's cozy development ecosystem any different than a user of Apple's cozy ecosystem? People seem to love the latter's setup but chastize the former.
Hey man, no judgement. I think it's great that the Microsoft ecosystem has developed a FOSS culture. There's not much point to saying "hey OUR FOSS community was first!" other than to say "the world you grew up in is not adjoined to the world i grew up in."
I'd also disagree with your assessment of Mac users. I would go so far as to say that so few people deploy to mac servers, that I can say "nobody deploys to mac" and no one would contradict me. All mac devs have to have at least a passing knowledge of linux.
A consequence of that is that mac using devs bump into (and have to rely upon) linux devs for expertise.
It also works the other way around. Async APIs have been standard in .NET for years, C#'s async support is much better than Javascript's. It would be great if both communities would learn more from each other.
"Many people left. In fact there was a stream of people leaving in the first 5 minutes or so, and many of them gave me "red cards" - the NDC scoring system method for saying "you really suck". One person sent me a message on Twitter that told me "You just waisted my time"."
I'm not a programmer but I do teach for a living. Going against the expectations of a large group requires considerable strength and courage, so well done to original author.
Of course, you can pay money to watch people code in clubs or pubs...
Sorry but I don't see how this would work for me. Sitting there for an entire 50 minute watching someone code? I would leave immediately. There's more to a talk than simply showing people how something works. Talks are about sending a clear and simple message to your audience. Highly detailed things simply tend to bore anybody, even fellow coders, and are also highly subjective.
> There's more to a talk than simply showing people how something works.
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..
If the goal is to make the audience focus on code, it's paradoxically full of distracting elements.
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.
It wasn't directionless, despite how it seems. I had a very clear-cut script and every demo was scripted to the letter. My problem was that I didn't have time to memorize it.
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 :)
Being an obnoxious french fry I'm actually akin to like the Dafts but here it just added to the overall confusion (my confusion I mean). I really think that some of your thoughts during and about the whole process would have been of better value.
I didn't read the backstory at the time of my comment, I apologize for that.
I haven't watched it yet (https://vimeo.com/43548699) but I am intrigued. I like the idea because it departs from the formulaic conference presentation which is becoming a chore in my view.
This format reminds me of the screencasts in youtube with no sound or some hard electro where people don't explain what it's going on in their heads. I find it frustrating and missing the point of actually communicating something.
You are just assuming people will get your "gesture" intentions.
I thought this was a great presentation - it completely sidesteps the issues of that always arise like "why should I try this"...or "but my tech stack does that already" and just shows people something new and interesting that they may not have seen before. Of course it relies of the fact that you've read your audience's exposure to the technology you are demoing correctly before going in to the conference.
It started a bit slow but I ended up watching the whole thing.
Not sure I agree with the comparison at the end to asp.net mvc and "waiting for a database to complete the request" - with mvc4 async controllers, .net 4.0 tasks and the new mvc 4.5 await keyword, async processing of web requests is pretty much a solved problem in the ms stack.
Not that node doesn't look like fun-as-hell to code-in - for that alone I would be willing to give it a go.
Async controllers don't solve this problem, they actually create 10 more. Same with tasks - you have thread locking issues, race conditions and other fun async stuff at the thread level. Node is single threaded, (basically) single process.
I get your point - that it's possible (it's always been) - it just isn't the way 99.99999% of the people use it.
Eh, that's a little bit of a FUDdy statement. You don't instantly have "locking issues" and/or "race conditions" to worry about just because you use an async controller with the TPL (async keyword in .NET 4.5). The only time you have to deal with locking and race conditions is if the work you're doing is trying to cooperate and/or touching a shared resource (e.g. a static field). In the most common/basic case of receive a web request, fire off a call to a database/remote service asynchronously and wait for it to come back before you continue processing the original request you don't have to worry about anything because you're not sharing any local state and I would hope the database/remote service you're talking to has its own locking.
That's not to say that there aren't merits to node's single threaded execution model in that, _when you do_ need to access a shared resource, you don't have to worry about locking/coordination, but that's a whole other debate. :)
I honestly didn't think it worked out and most people I talked to after the session didn't think it worked either. To put it lightly: People had rather mixed impressions.
He was progressively writing Node.js-code without explaining any of it in detail. His way of illustrating what his code was doing, was by cross-referencing his Node-stuff to some Ruby-based BDD framework.
How do I connect that to Node? Do I need Ruby to run node?
It came off wrong to most people. Especially with the techo-music glaring in the background, some people thought he just wanted to show off how cool he was and brush his own ego.
Other's complained that if you could actually follow his demos, you already knew the stuff he was demoing, so what was the point? So what had you just learned?
And like he said: Some people directly told him it was a waste of time.
IMO it was an interesting idea taken too far.
He makes it come off as a success, but I think that is disingenuous. This session probably disappointed more spectators than any other session on that conference. And I say that as someone who knows how good Rob can be when he's at his best.
So don't be afraid to experiment. But be prepared to see your experiments fail. Every now and then they will. Even for a guy like Rob. Especially when you take it to the extreme, like he did here.