3 ms·

The irony I find in this depiction is the "hot new" stuff in today's ecosystem is very often stuff that's already existed for 2-3 decades in some less trendy fo

The irony I find in this depiction is the "hot new" stuff in today's ecosystem is very often stuff that's already existed for 2-3 decades in some less trendy form, given a new brand identity (complete with cookie-cutter .io website), and grows a Twitter & conference clique around it as though it's being discovered for the first time. "Reactive", "Streams", "Containers", "NoSQL", "Big Data", "Blockchain", the list goes on. I work, or have recently worked, in each of those problem domains to a non-trivial extent, so I'm absolutely no stranger to the leading edge of the marketplace, but I still find it amusing how gaga people get over the new branding, and I'm even more amused how indignant people get when you show them work from 15-20 years ago that was materially similar under the "hot new" brand name it had back then. Sure the show might be new to a lot of people, but to a lot of other people it's just re-runs that have been in syndication for a long time with tired plot devices and predictable story arcs. Reluctance to jump on the bandwagon may very well be rooted in the scar tissue built up the last time around, not purely reticence to try something new. They may just be withholding their enthusiasm until they try can something actually new.

yanilkr 10y ago
When you work in a team with other people, certain collaboration skills are useful and necessary. I am god and have seen it all and i am going to reject other's ideas is not a productive attitude. Cost conscious managers are going to ask tough questions like if you are so good why are you competing with a 3 years experience software dev?
- im_down_w_otp 10y ago
  Being reluctant to readily abandon "tools and ideas that worked for them in the past" in favor of adopting HN-buzzword-compliant technologies on flimsy pretext being presented by earnest people who nonetheless often have limited experience with the thing they're proffering and more often zero awareness of the similar fads that came before it is really, really far away from, "I am god. I've seen it all. I reject it all!" Cost (dev, support, maintenance, etc.) conscious managers are going to ask tough questions like, "Why would we use Node.js and MongoDB to build a financial transaction processing switch?" and "Why would we deploy a Hadoop cluster to do offline analysis of only 4GB-5GB of transient data per day?" and "Why would we front Elasticsearch with Kafka when our write-load is well below what a small ES cluster can handle and the data is non-critical?" and "Why would we deploy Mesos for infrastructure of <20 machines that has no dynamic multi-machine scheduling needs and never will?" There's an almost never-ending barrage of stuff like that I contend with. Which is fine. It's part of my job, and despite hard-earned cynicism... myself and my teams have still managed to build all manner of things with all manner of relatively esoteric tech. Erlang, Rust, Elixir, Scala, Cassandra, Riak, HBase, Kafka, Storm, Spark, Ansible, Cobbler, Packer, Consul, Vault, LING, Rumprun. No stranger here to including feedback and ideas to determine the best tools for the job that needs doing and their associated costs (dev, support, maintenance, etc.). I'm also no stranger to the flights of fancy that beset engineers who end up inventing reasons or overstate their problem space in attempts to justify using new shiny things. Take it easy mate. Cheers!
  - yanilkr 10y ago
    Everything you said needs to be judged based on the context. There is also a case of tallest tree grabbing all the sunlight and overshadowing other potential talent. If you want to build a strong resilient team you should allow your devs to fail. For your every valid example I can show you terrible choices people make in realworld because someone with a lot of experience told this was the perfect thing to do and they resisted changes. Ofcourse you have to exercise sound judgement in everyday life. I have seen managers who are reluctant to hire rockstars simply because they don't need them.
naveen99 10y ago
What is your analogue to bitcoin from a decade ago ? Merkel trees are old (1979), Hashcash goes back to 1997 https://en.m.wikipedia.org/wiki/Hashcash https://en.m.wikipedia.org/wiki/Hashcash But bitcoin is not just a rebranding of a combination of hashcash, merk trees, forth, pgp, BitTorrent. Also what is the analogue to reactive in the past ? The main reason for reactive is different screen sizes and orientation of handheld devices. What similar problem would reactive have solved 2 decades ago ? There are a couple of references from 2001 and 2004 https://en.m.wikipedia.org/wiki/Responsive_web_design https://en.m.wikipedia.org/wiki/Responsive_web_design , but really there wasn't a practical common use case before the iPhone in 2007 and ipad in 2010.
- im_down_w_otp 10y ago
  "Blockchain", not bitcoin, and "Blockchain" is quite literally a specific application of Merkle Trees and Merkle Proofs, and they've been used almost exactly like this in payments clearing & settlement + dispute systems for tranlog coherency checks and resolution for a long time. "Reactive", as in http://www.reactivemanifesto.org/ http://www.reactivemanifesto.org/, and it's manifestations in various Akka projects like http://www.reactive-streams.org/ http://www.reactive-streams.org/. Reading the "manifesto" reads like somebody going to really, really extensive lengths to talk about Erlang without actually saying "Erlang" and that's been around publicly, along with its runtime semantics, since 1998.

yanilkr 10y ago

When you work in a team with other people, certain collaboration skills are useful and necessary. I am god and have seen it all and i am going to reject other's ideas is not a productive attitude. Cost conscious managers are going to ask tough questions like if you are so good why are you competing with a 3 years experience software dev?

im_down_w_otp 10y ago
Being reluctant to readily abandon "tools and ideas that worked for them in the past" in favor of adopting HN-buzzword-compliant technologies on flimsy pretext being presented by earnest people who nonetheless often have limited experience with the thing they're proffering and more often zero awareness of the similar fads that came before it is really, really far away from, "I am god. I've seen it all. I reject it all!" Cost (dev, support, maintenance, etc.) conscious managers are going to ask tough questions like, "Why would we use Node.js and MongoDB to build a financial transaction processing switch?" and "Why would we deploy a Hadoop cluster to do offline analysis of only 4GB-5GB of transient data per day?" and "Why would we front Elasticsearch with Kafka when our write-load is well below what a small ES cluster can handle and the data is non-critical?" and "Why would we deploy Mesos for infrastructure of <20 machines that has no dynamic multi-machine scheduling needs and never will?" There's an almost never-ending barrage of stuff like that I contend with. Which is fine. It's part of my job, and despite hard-earned cynicism... myself and my teams have still managed to build all manner of things with all manner of relatively esoteric tech. Erlang, Rust, Elixir, Scala, Cassandra, Riak, HBase, Kafka, Storm, Spark, Ansible, Cobbler, Packer, Consul, Vault, LING, Rumprun. No stranger here to including feedback and ideas to determine the best tools for the job that needs doing and their associated costs (dev, support, maintenance, etc.). I'm also no stranger to the flights of fancy that beset engineers who end up inventing reasons or overstate their problem space in attempts to justify using new shiny things. Take it easy mate. Cheers!
- yanilkr 10y ago
  Everything you said needs to be judged based on the context. There is also a case of tallest tree grabbing all the sunlight and overshadowing other potential talent. If you want to build a strong resilient team you should allow your devs to fail. For your every valid example I can show you terrible choices people make in realworld because someone with a lot of experience told this was the perfect thing to do and they resisted changes. Ofcourse you have to exercise sound judgement in everyday life. I have seen managers who are reluctant to hire rockstars simply because they don't need them.

naveen99 10y ago

What is your analogue to bitcoin from a decade ago ? Merkel trees are old (1979), Hashcash goes back to 1997 https://en.m.wikipedia.org/wiki/Hashcash https://en.m.wikipedia.org/wiki/Hashcash But bitcoin is not just a rebranding of a combination of hashcash, merk trees, forth, pgp, BitTorrent. Also what is the analogue to reactive in the past ? The main reason for reactive is different screen sizes and orientation of handheld devices. What similar problem would reactive have solved 2 decades ago ? There are a couple of references from 2001 and 2004 https://en.m.wikipedia.org/wiki/Responsive_web_design https://en.m.wikipedia.org/wiki/Responsive_web_design , but really there wasn't a practical common use case before the iPhone in 2007 and ipad in 2010.

im_down_w_otp 10y ago
"Blockchain", not bitcoin, and "Blockchain" is quite literally a specific application of Merkle Trees and Merkle Proofs, and they've been used almost exactly like this in payments clearing & settlement + dispute systems for tranlog coherency checks and resolution for a long time. "Reactive", as in http://www.reactivemanifesto.org/ http://www.reactivemanifesto.org/, and it's manifestations in various Akka projects like http://www.reactive-streams.org/ http://www.reactive-streams.org/. Reading the "manifesto" reads like somebody going to really, really extensive lengths to talk about Erlang without actually saying "Erlang" and that's been around publicly, along with its runtime semantics, since 1998.