"It's never too late to have a happy childhood." - Tom Robbins

That's super. 99% likely do not understand the depth of this statement.

You have just told me why I absolutely should not hire you, at least while you have that attitude. Someone who cannot respond positively to negative feedback is what we call "unmanageable". Nobody is perfect, so nobody can do a job perfectly. And when (not if) you screw up, it is definitely your manager's job to provide feedback, whether or not you want to hear it. You can hope your manager is experienced enough to deliver the feedback in a constructive way, but even if not, you need to be adult enough to take it in stride, learn from the experience, and do better next time. Welcome to the real world.

I may have phrased the question wrong, but I meant the other way around. If I did work for you, would you provide me with feedback if I didn't ask for it?

Of course I would. That's part of managing.

And if you was a freelancer instead of an employee? or a coworker?

How about Spore.js? It's a nice contraction of SproutCore, and doesn't sound as silly as the spoonerism KrautSpore :)

If they are such experts, how would they not be aware of waterfall? Either they are idiots who have no clue about software development methodology, or they are just lying (either to their customers or themselves). It's not like it's hard to find a reference to waterfall if you bother to look.

One of my favorite Alan Kay quotes: "Make simple things simple, and complex things possible." And the Albert Einstein quote everyone mangles: "A scientific theorem should be as simple as possible, but not simpler." It's a matter of finding the sweet spot where the system is easy enough to learn to be accessible, and sophisticated enough to be powerful. In terms of usability, I've generally been happy with where Rails falls on that spectrum. The real challenge with Rails is learning the codebase well enough to make effective contributions to the framework.

I agree. Look at nginx vs apache - competition with nginx has done a lot to improve apache. Merb did more to improve Rails than anything else has. New projects with different design centers give you the flexibility to try out approaches that wouldn't be possible in the old project.

The thing that sucks is people taking sides and getting all bent out of shape over things. Even the people behind "competing" projects can cooperate in their work. Ruby MRI, JRuby, Rubinus, Maglev - all these supposedly competing projects created collaboration on RubySpec and other shared pieces of technology. When John Trupiano and I collided over Rack::Rewrite vs Refraction, we just talked on IRC and had a friendly chat about our different approaches and motivations, and how features in one project influenced the other. Nobody got mad or hated anyone over it. Even major political rivals can be close friends - look at James Carville and Mary Matalin (or don't, if you value your peace of mind).

Most "competing" projects are not friendly: marketing materials put out deride the alternative as "slow", "buggy", or what-have-you (some of the stuff put out about my project simply makes me want to quit it is so nasty).

Interesting, then, that, for whatever reason, I do /not/ see this kind of behavior with the various Ruby implementations: most people I deal with in that community actually seem to enjoy the various versions existing and work together. In this case, I wouldn't even call it "competition": I'd call it "cooperative experimentation".

But this argument breaks down when you look at the nginx vs. Apache example: proponents of nginx tend to just pummel Apache with pain, even when many of the claims aren't even true (which is extra stupid as I don't even think it is correct to believe that nginx and Apache are trying to solve the same problem).

This is the seriously awesome talk Coda Hale gave at GitHub's CodeConf in April, reprised at Pivotal Labs in June. The live video isn't the best quality, but the quality of the talk more than makes up for it. And the slides and audio are just fine, so no worries about watchability.

Switching sides is good when you're sitting side-by-side. But I haven't noticed that there's enough neck twisting in the tete-a-tete configuration for that to be an issue.

That's correct. We just let them use the space; we don't code with them.

Wow!

Being co-located I would hope folks would have taken an interest and the Diaspora folks having enough maturity to ask for early feedback from the more experienced folks in the room from Pivotal or others.