Try It Quiet
wekeroad.com
wekeroad.com
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.
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.
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.
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!
:)
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.
"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.
"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.
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.
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...
http://www.wired.com/science/discoveries/news/2006/07/71248
Typing in front of a large audience is a strange experience. Requires practice.
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.
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.
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.
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 very much get the feeling (though I could be wrong) that you didn't do so to be "disruptive", to garner the attention.
If you would have stated what you were doing, it would have accomplished the same goals, but it wouldn't have caused such a hoopla.
Disregard my comments. :)