They clearly haven’t tried navigating treatment options in markets without insurance. I’m glad they are privileged enough (from the insurance) to make those complaints.
4,165 karma · joined May 20, 2018
1. many organizations dismiss ML solutions without actually trying them. Rather, if one hack week style prototype doesn’t work on the first try, it’s chalked up to “over hyped AI” and never sees the light of day. Organizations that succeed with ML don’t do it that way. Instead they ensure the success criteria are stated up front and measured throughout, so you can see why it didn’t work and iterate for v2 and v3. “We spent a bunch of R&D expense on magic bullet v0 and it didn’t succeed immediately” is a leadership and culture problem - you probably can’t succeed with ML until you fix that.
2. Many companies have no idea how to staff and support ML teams, and go through various cycles of either taking statistical researchers and bogging them down with devops or taking pure backend engineers and letting them do unprofessional hackery with no clarifying product quality ML expert in the loop.
You need a foundation of ML operations / infra support that cleanly separates the responsibilities of devops away from the responsibilities of model research, and you must invest in clear data platform tools that facilitate getting data to these teams.
If an org just figures they can throw an ML team sink or swim into an existing devops environment or they can require an ML team to sort out their own data access, it’s setting ML up for disaster - and again you’ll get a lot of cynics rushing to say it’s failing because ML is just hype, when actually it’s failing due to poor leadership, poor team structure and poor resourcing.
This is the way it works for a lot of therapy and mental health services and it’s horrible. Prices are absolutely insane, practitioners are not accommodating to patient schedules, and patients have absolutely zero bargaining power.
In some ways doing it through insurance is kind of like a union. You all agree to accept certain inefficiencies, bureaucracy, etc., (and associated cost) in order for better collective bargaining terms.
Of course people with great jobs usually don’t care about unions. They don’t need the collective bargaining power and thus figure the bureaucracy cost is just a loss they don’t need.
Same thing with very healthy people and insurance. If you’re healthy you just figure, give me cheap catastrophe insurance, what do I care? But if you’re in the depths of the medical industrial complex because you need frequent treatment for chronic conditions, you quickly learn that papering everything over with lots of bureaucracy to adhere it to better collective bargaining for patients is way better, and I’d rather take the nasty, churning quagmire of price inflating insurance than deal with spartan libertarian mini-insurance that essentially just results in rich-get-richer (i.e. genetically lucky healthy people just get to save money while everyone else suffers).
Speaking as someone who never had Facebook, I’ve experienced zero loss of connection with anyone in many networks of family, friends, colleagues, etc. Just a simple email thread to share stories and photos here or there, phone calls, SMS text chats or other apps. It’s so easy and seamless to stay in touch with no part of it involving Facebook.
But that has nothing to do with the long-term valuation of cryptocurrency. The part I object to, which is what many of the earlier comments are trying to say, is some version of “Tether & wash trading is bad, therefore bitcoin is nothing but hype / fake scams.”
In other words, I’ll be happy if bitcoin crashes from Tether (I believe it will, probably to well under $20,000) - that is nothing more than a huge buying opportunity.
No matter where you live in the world, you don’t need Facebook, not at all, not one bit. It requires absolutely zero extra effort to stay in touch to exactly the same degree, see all the photos, send all the messages you want, with dozens and hundreds of other global services that all your contacts, even tech-phobic grandma, already can super easily interact with.
I have never had a Facebook account, yet I still keep in touch with all the many contacts in my network from high school, college, past jobs, global extended family, immediate family, OSS project acquaintances, etc. etc. - all with zero Facebook.
This utterly false myth that Facebook is necessary, or even the slightest bit important or even useful, to keep in touch very closely with all the photos, comments, etc., really needs to die.
You can completely delete Facebook on a whim right now, and 100% of all that stuff is just as immediately, easily achievable right away with zero loss or deficiency from removing Facebook.
This is disgusting behavior on your part. You should be ashamed. Even more so for the mental gymnastics you’ve written in this spastic and bizarre comment to defend and endorse using flippantly insulting language.
The level of intellectual dishonesty in what you say is just staggering. Absolutely shambolic on your part.
It reminds me of the disgusting and flagrantly ridiculous thread from Stephen Diehl that was on HN recently, more comments here:
You could just as easily say something like, “People who take TDD to an extreme are hard to work with and ultimately their inflexibility and unwillingness to appreciate other approaches does more harm than good.”
See how that’s not dehumanizing? See how that accomplishes the same thing without disgusting juvenile insults like saying someone of a different ideology has a “frail little mind”?
> “TDD purists are just the worst. Their frail little minds can't process the existence of different workflows.”
Imagine thinking about colleagues as people with “frail little minds.” Yikes.
Many of the other points betray serious attitude and perspective problems, but it was forgivable until getting to that last bullet and realizing, no, this is just a person with a shitty attitude.
This article is the example of wasting time and money. It’s amazing to me the way anti-machine-learning sentiment causes people to do a complete 180 from common sense just to avoid actually investing minimal levels of resource or effort to study and understand problems where statistics can help.
A big observation in my career is that statistics makes non-statisticians go crazy in the head. People panic that statistics will be used to usurp their authority and then try to steamroll statistics with politics about what is or isn’t over-hyped and what would or wouldn’t be a “waste” of time or resources to try out.
In the bio blurb they self-describe as an infra engineer who also enjoys data science. In some sense I really don’t like to see that. The quality of the data science / ML work in this is actually quite bad, but people use these blog posts as resume padders to try to jump into ML jobs without ever having any real experience or training.
I think it’s a bad thing because it devalues the importance of real statistical computing skills, which are very hard to develop through many years of education and experience - absolutely not the sort of thing you can get by dabbling in some Python packages on the weekend to do a little project like this.
The amount of waste I see from companies trying to avoid paying higher wages and avoid team structures that facilitate productivity of statistics experts is staggering - with all kinds of hacked up scripts and notebooks stitched together without proper backing statistical understanding, making ML engineers manage their own devops, and just ignoring base statistical questions.
For this drive problem for example, I expect to see a progression from simple models, each of which should address class imbalance as a first order concern. I expect to see how Bayesian modeling can help and how simple lifetime survivorship models can help. I expect to see a lot of feature engineering.
Instead I see an infra engineer playing around with data and trying one off the shelf framework, then claiming the whole premise can’t work in production.
For example, in this post the engineer does not adequately handle class imbalance at all, and reaches for a hugely complicated model framework (XGBoost) without even trying something like bias-corrected logistic regression first.
I think this post is just an example of an infra engineer thinking “ML is easy” and when their quick attempt doesn’t work, then just bailing and saying “ML is overhyped and doesn’t work for my problem.”
No, you very much can rule that out. It’s nothing more than “a broken clock is right twice a day.” Lots of people are making lottery like bets on specific stocks, with a just-so story about why they’ve correctly valued it. By random chance, some small subset actually pay off and people falsely mistake the just-so narrative for investor prowess or foresight.
Anyone who would put enough portfolio weight on a single stock, whether Tesla or Gamestop or whatever, that mere 10x price appreciation would amount to something significant is failing to diversify and carrying huge huge single name risk.
There’s nothing to see here. Put money in a broad basket of stocks and go do something else.
Just legal validation alone would take weeks even under emergency round-the-clock conditions. It’s the same with most open and shut zero-tolerance style firings as well, for all but the most fungible roles.
This largely has nothing to do with how grievous the transgression is or how sincerely the management wants to do the right thing. It has to do with red tape that is designed from first principles to permit zero exceptions or special cases that can cut through it quickly.
It would require refactoring not just Apple’s red tape infrastructure but the entire concept across virtually all of corporate America to optimize for speed of firing vendors based on child exploitation.
It’s like choosing an O(n^2) algorithm, baking it in as a load-bearing centerpiece, then being upset something doesn’t happen in O(1).
> “ Technosolutionism is a way of understanding the world that assigns priority to engineered solutions to human problems. Its first principle is the notion that an app, a machine, a software program, or an algorithm offers the best solution to any complicated problem.”
But you can’t escape science. Whatever is a solution, if it can be reduced to repeatable physical processes and computational substrates, is amenable to engineering and engineering has almost universally made such solutions more scalable, more reliable, safer, more affordable and so on.
I think there is a dangerous Luddite narrative underpinning this that ultimately is not self-consistent and likely to do more harm than good.
Also anecdotally, as an introvert, I can’t overstate how much happier I feel working from home. I’ll take all the flaws of videoconferencing any day, over the constant fight-vs-flight reflex exhaustion of open plan offices and a constant stream of in-person interaction when I need solitude and privacy to get mental clarity about my work.
It helps precisely so you don’t pay premature abstraction costs to over-generalize the performance patterns.
One of my biggest complaints with Julia is that zealots for the language insist these permeating abstractions are costless, but they totally aren’t. Sometimes I’m way better off if not everything up the entire language stack is differentiable and carries baggage with it needed for that underlying architecture. But Julia hasn’t given me the choice of this little piece that does benefit from it vs that little piece that, by virtue of being built on top of the same differentiability, is just bloat or premature optimization.
> “you should rewrite your algorithm in a lower level layer just to support complex numbers.”
Yes, precisely. This maximally avoids premature abstraction and premature extensibility. And if, like in Cython, the process of “rewriting” the algorithm is essentially instantaneous, easy, pleasant to work with, then the cost is even lower.
This is why you have such a spectrum in Python.
1. Create restricted computation domains (eg numpy API, pandas API, tensorflow API)
2. Allow each to pursue optimization independently, with clear boundaries and API constraints if you want to hook in
3. When possible, automate large classes of transpilation from outside the separate restricted computation domains to inside them (eg JITs like numba), but never seek a pan-everything JIT that destroys the clear boundaries
4. For everything else (eg cases where you deliberately don’t want a JIT auto-optimizing because you need to restrict the scope or you need finer control), use Cython and write your Python modules seamlessly with some optimization-targeting patches in C/C++ and the rest in just normal, easy to use Python.