5 ms·

These are perfect examples of cargo cult and your comment confirms it. Just because some successful company adopts a technology it doesn't mean that it suits yo

These are perfect examples of cargo cult and your comment confirms it. Just because some successful company adopts a technology it doesn't mean that it suits your needs. You could have completely different problems and adopting those solutions can be in the very best case useless and in all the other cases harmful. You need to adopt a solution because it fits your problem, not because "the most successful companies in the world" are using it. It's always a good thing to know that these technologies exists and what are they used for, but jumping on the hype wagon without understanding deeply the original problem that they solve, how the solution works, and most importantly if it applies to your use case trying it with some representative, real work in your project, it is a sure recipe for failure.

sanderjd 10y ago
This is not charitable to the comment you replied to. That comment suggested that looking at what companies have had success with is a no-brainer, and you interred they were suggesting "jumping on the hype wagon without understanding deeply the original problem that they solve". Here, I'll quote: > You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it. I think you're both saying the same thing. People should look at what others are doing, and analyze the suitability to their own use case. I think this is exactly what people do. I've never seen a tool choice postmortem that concluded, "well we only chose it for hype, and that was stupid". It's always a specific thing that you thought would work better than it did. For example, I came away from a project quite burned by Angular 1.x. It wasn't that we chose it because of hype that it was a poor choice, it was that the directive system did not make it as easy to build modular components as initial prototypes suggested it would be. React was then interesting to us (though we never pursued it on that project), not because of upvotes on HN, but because it scratched that itch better. I guess I just don't see this wild hype cycle that everyone complains about - I just see people trying to scratch itches they have, sometimes making the right choice, and sometimes making the wrong choice.
v89 10y ago
I agree, I thought the article was kind of BS-y until it got to the example section which I thought was spot on.
staticassertion 10y ago
It would be one thing if we just knew these companies used these technologies, and that was it. Instead, we have conference talks, testimonials, and evidence that they are working well for them. Obviously you should not use a technology without understanding it. Does this really require a discussion? No one is on the other side. But going "Well that technology is just hype" isn't understanding it, it's dismissing it.
- cle 10y ago
  Conference talks, testimonials, etc are often biased towards the positive. It drives me nuts when someone tells me why I should use some technology, without telling me why I shouldn't use it, and what its constraints and limitations are. Those are equally as important as the features. Project documentation are the worst at this, painting a rosy picture of how the tech will solve the world's problems, without telling you the practical realities of using it.
  - staticassertion 10y ago
    Right, because there isn't a litany for what could go wrong with every single technology mentioned in this article already... Let's not pretend like there's a single technology out there that isn't constantly under fire. If you strip out the strawman argument against each technology ("Let me tell you a story about how this technology didn't work in my imagination") you end up with one single premise - do research before adopting tech. Did you need to be told that? I think if one single person is making tech stack decisions in production and no one is going "uh can you justify this" you have far more serious issues.
    - cle 10y ago
      No I don't need to be told that. That's my point. Most tech products make it difficult for me to do my up-front research, because they want to paint a rosy picture of their product to drive adoption. But I'm less likely to adopt it if I can't easily understand its constraints, failure scenarios, scaling bottlenecks, maintenance headaches, leaky abstractions, etc.
mkesper 10y ago
It's not only about programming: Facebook uses open offices, so MUST we!

sanderjd 10y ago

This is not charitable to the comment you replied to. That comment suggested that looking at what companies have had success with is a no-brainer, and you interred they were suggesting "jumping on the hype wagon without understanding deeply the original problem that they solve". Here, I'll quote: > You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it. I think you're both saying the same thing. People should look at what others are doing, and analyze the suitability to their own use case. I think this is exactly what people do. I've never seen a tool choice postmortem that concluded, "well we only chose it for hype, and that was stupid". It's always a specific thing that you thought would work better than it did. For example, I came away from a project quite burned by Angular 1.x. It wasn't that we chose it because of hype that it was a poor choice, it was that the directive system did not make it as easy to build modular components as initial prototypes suggested it would be. React was then interesting to us (though we never pursued it on that project), not because of upvotes on HN, but because it scratched that itch better. I guess I just don't see this wild hype cycle that everyone complains about - I just see people trying to scratch itches they have, sometimes making the right choice, and sometimes making the wrong choice.

v89 10y ago

I agree, I thought the article was kind of BS-y until it got to the example section which I thought was spot on.

staticassertion 10y ago

It would be one thing if we just knew these companies used these technologies, and that was it. Instead, we have conference talks, testimonials, and evidence that they are working well for them. Obviously you should not use a technology without understanding it. Does this really require a discussion? No one is on the other side. But going "Well that technology is just hype" isn't understanding it, it's dismissing it.

cle 10y ago
Conference talks, testimonials, etc are often biased towards the positive. It drives me nuts when someone tells me why I should use some technology, without telling me why I shouldn't use it, and what its constraints and limitations are. Those are equally as important as the features. Project documentation are the worst at this, painting a rosy picture of how the tech will solve the world's problems, without telling you the practical realities of using it.
- staticassertion 10y ago
  Right, because there isn't a litany for what could go wrong with every single technology mentioned in this article already... Let's not pretend like there's a single technology out there that isn't constantly under fire. If you strip out the strawman argument against each technology ("Let me tell you a story about how this technology didn't work in my imagination") you end up with one single premise - do research before adopting tech. Did you need to be told that? I think if one single person is making tech stack decisions in production and no one is going "uh can you justify this" you have far more serious issues.
  - cle 10y ago
    No I don't need to be told that. That's my point. Most tech products make it difficult for me to do my up-front research, because they want to paint a rosy picture of their product to drive adoption. But I'm less likely to adopt it if I can't easily understand its constraints, failure scenarios, scaling bottlenecks, maintenance headaches, leaky abstractions, etc.

mkesper 10y ago

It's not only about programming: Facebook uses open offices, so MUST we!