HN user

ighost

106 karma
Posts11
Comments62
View on HN

I know how you feel.

I've worked at a couple of startups, two groups at Apple, two groups at Google and now at Twitter. I've learned two things chasing a feeling of fulfillment, like you seem to be:

1. You can't expect your job to give you the all of the fulfillment you need.

2. The most fulfilling work is the kind of work that's just challenging enough, but not too challenging--http://en.wikipedia.org/wiki/Flow_(psychology)

The authors makes it sound like after designing the UX, the implementation will become trivial. I think this is a bit naive because most serious applications go through many iterations of UX. Some of these changes will be small and not require significant re-plumbing, but others will necessitate a lot of behind-the-scenes churn.

My point is that it's better to design the plumbing of an application with some longer-term considerations than just "what do we need to implement that UI wireframe."

Minimal viable products are cool and all, but let's not use that as an excuse to write something that will need to be thrown out wholesale to add that big traction-building feature.

Yes, Javascript the language is getting better support in browsers, but DOM manipulation without a framework (like jQuery) is still horrible.

The Todos example is handy, but not every app is a todos app, and there's plenty of Backbone functionality that is not exercised in this simple app.

And when there isn't an existing example of what I'm trying to do close at hand, I find the Backbone docs to be quite good.

> I would posit here that nothing I could do in best practice would have caught the offending line.

bullshit.

jslint or clojure compiler would have found this error at "compile time."

coffeescript would have made it a non-issue.

Curl vs Wget 16 years ago

kinda banal if you ask me. it's two simple tools that do approximately the same thing. even grep vs ack would be more interesting.

no offense to the authors of course, they did a great job in both cases.

I wish someone would publish this "tasteful subset of C++," kind of like Douglas Crockford's Javascript: The Good Parts. Then I could just learn that and skip all the crazy template shit.

I agree that polymorphism is the "right way" if there's already a class hierarchy established.

If the superclass-subclass relationships aren't in place for you (worse yet, they're not set up how you want them to be set up), this hack accomplishes a similar effect with no refactoring.

Synthetic? Yes. Contrived? No. I've seen this sort of thing in my own and other people's Java code, where you know what class it is but not the most-derived subclass. That's how polymorphism happens.

You're mistaken.

Animal animal = zoo.getAnimal();

Can I do animal.bark() or animal.fly() ? All I know is that it's an Animal of some sort, may or may not be an instance of the Dog or Bird subclasses of Animal.