3 ms·

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

by 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.

by yanilkr 10y ago

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.