javadocmd

Copilot copilot Copilot copilot copilot copilot Copilot copilot.

https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...

A good question worth considering, IMO. Take the Susan G. Komen Foundation as a present-day example of a foundation that, although founded with a righteous cause in mind, has (in some folks' estimation) lost its way, and/or become a somewhat negative force on cancer treatment, women's health, and charity efforts generally. https://en.wikipedia.org/wiki/Susan_G._Komen_for_the_Cure#Co...

Of course for a foundation that relies heavily on continuing donations, the "market" (so to speak, in this case arranged for the generation of social good) can send a corrective signal by cutting donations. For a completely self-sustaining trust, it stands to reason that society would have little chance to "fix" a wayward organization.

You've not refuted the article so much as pointed out a corner case the author didn't address in which ML is a good fit. Your example, using ML to perform the medical coding function, is using a data source (in this case the EMR) for one of the purposes for which it was explicitly designed and for which it is (arguably) non-deficient. That is a realm not doomed to failure.

The realm doomed to failure is using a data source for a completely oblique purpose for which it is horribly distorted. Namely, the purpose of optimizing individual and public health by discovering guidelines and treatments, diagnosing illness, and delivering optimal care.

(Of course medical billing as an enterprise shouldn't even exist, but that is another topic.)

A bit like Captain Renault proclaiming his shock at finding gambling in Rick's cafe.

If we go around breaking windows we could really bolster the world's window-making capacity.

I wish the first thread I saw was this enthusiastic about Brother. I've got an HP delivering today because it sounded like the Linux driver support was more solid -- didn't see a mention of this proprietary cartridges nonsense. Mea culpa for not doing more research I guess.

You invented "Chutes and Ladders: Legacy".

If the hot startup trend suddenly became lean hospital systems, you'd see all sorts of articles about the ideal attending-to-resident physician ratio.

Worth noting that the author makes a significant claim without any citation:

> That vaping works as a way to quit smoking... seems clear.

Studies have been fairly limited so far, given the recency of e-cigarettes (relative to science's timescale). And the studies that we have seem pretty mixed: some showing benefit over other accepted smoking cessation methods, some not. Some showing higher relapse rates in the e-cigarette group. Nothing about that seems clear to me.

What they didn't report is the corresponding decrease in labor costs. If they save 1M in labor to lose 850K, they're still ahead.

> You know someone somewhere got a can of creamed corn.

But the point was you don't know that. If they get deluged with creamed corn, it might just sit in a warehouse, get shipped to a different community, or even get trashed. Donate a can if you prefer, just don't fool yourself with false guarantees.

If this had launched with Slack support two months ago, I'd have saved a few days development time. Interested to see the pace of partner adoption.

I would argue that even the ideal medical system would likely produce the same outcomes experienced by the author of the parent post. In our present stage of scientific and technological advancement, the following might as well be a Law of Nature: even the best of drugs will have varying effects on various people in varying circumstances.

But yes, there are plenty of inadequacies in our healthcare industry (speaking from the US), but that's a much, much broader discussion.

How can we do better?

This is how you know it was written by an engineer. The executive summary is at the bottom.

Forgive me for being blunt, but that's just how modern medicine works. No one has the Star Trek tricorder that can scan your body, read your genome, and detect a quantum fluctuation in your synaptic waveform matriculation to calculate how many CCs to put in the hypospray.

We really only have one amazing piece of technology at our disposal: statistics. At the absolute best (and I'm not saying it's always the best...), what comes out of a pharmaceutical development pipeline is a drug that works for some people some of the time. Sure, sometimes you get broad categories to try to narrow down effectiveness, but at the individual level there is ultimately no choice but to try a drug and see if it works. And this is especially true in psych drugs, in no small part because there are so many unanswered questions about how our mind works.

And that sucks. I get it. It must be so frustrating to deal with a revolving door of new regimens and new side effects, all while yearning for relief from the underlying ailment. Not to mention navigating our nightmarish medical bureaucracy. But please understand that doctors, generally, are just doing their best to help given the tools they have. If you don't currently have that kind of trust and partnership with your doctor, I hope you are able to find one with which you can. I wish you the best, and hope that this perspective will make your frustrations somewhat easier to bear.

And don't forget the related metric: "number needed to harm". Physicians practicing good, Evidence-Based Medicine also weigh how many patients are likely to be impacted by harmful side effects.

In an example from The NNT about PSA Screening for Prostate Cancer: http://www.thennt.com/nnt/psa-test-to-screen-for-prostate-ca...

No benefits were identified to PSA screening, while 1 in 5 will go on to have an unnecessary prostate biopsy (which can itself lead to complications, false-positive diagnosis, and further treatment with associated complications, and so on).

(I feel obliged to mention that I'm not a doctor, btw, just sort of a casual fan of medical science and stats.)

As someone with a basic understanding of thermodynamics, I'm highly offended by the assertion that their cooling technology is "energy free".

In addition to tibbett's point (expressing technical accomplishments in terms of their value to the business), do some honest introspection on your value to your peers. I'm really just elaborating on Ms. Botros' article here, but for example you want to ask yourself these kinds of questions:

Do you improve the skills of the people around you? Do you identify and help resolve barriers faced by your peers? (This doesn't always mean fixing things yourself!) Do you improve the environment and culture where you work? Can you work collaboratively to establish a vision for change? How do you gain the buy-in of your peers when it comes time to implement change?

Internalizing these answers will prepare you to steer the conversation onto the skills that you know are important for the role.

I would argue that company-specific historical knowledge is not the value you (et al) are bringing. The value is the soft-skills of effective leadership that distinguish Principal from Senior (to use the article's parlance). Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills. And, of course, in finding a company and an interview panel that understands their value.

Anyone worth their salt should realize that the long-term value of technical leadership far eclipses the short-term value of knowing what happened that one time we tried switching from Technology A to Technology B. (And unless you've completely purged your engineering department, such institutional knowledge is there to be queried.)

I tend to agree, although with most things I think it depends on how heavily invested you are. Migrating a handful of mission-critical Lambdas is no biggie, but if you've really bought the bait and implemented your entire web services architecture on AWS API Gateway and Lambda -- for some reason -- you've got a much tougher job untangling yourself. Perhaps it suffices to say it's worth keeping an eye on how much friction you're building for yourself as you go.

I like using ACLs for my coarse-grained "this subnet is allowed to talk to this subnet" rules, and security groups for everything finer-grained. Maybe I'm over-cautious, but I don't want one rogue security group opening up a tunnel to sensitive subnets.

Partial function application would be sweet. I wind up manually currying a lot of functions and readability starts to get sketchy.

  const foo = (a: number, b: number): number => { /*...*/ }

to

  const foo = (a: number) => (b: number): number => { /*...*/ }

To be more precise, this was a decision made by the governor's office which essentially allowed these companies to act with very little regulation or oversight.

I think it's fair to say that the governor's office is less representative of (capital P) the People than, say, the state legislature or even a ballot measure. So yes, Arizona's elected government was involved, but that government opted to be as minimally involved as they could possibly be.

Personally, I would feel much happier with some dedicated oversight and some levers to pull if companies appear to be doing anything besides making the safety of Arizonans their number one priority.

The tricky case is a bucket which is otherwise private but contains individual files that were uploaded with a public ACL (or had the ACL modified, of course). This is not made apparent anywhere in the interface (by which I mean there isn't some big "public" sticker), and is part of what this feature is trying to address.

Better than hoping your customers are carrying their own detection device, build such a detection mechanism into the rear of the card slot and have it periodically "sweep" itself.

I went from Java to (dabbling in) Scala to TypeScript. While my heart is still with Scala, the ecosystem around Node is incredibly persuasive. The speed with which you can accomplish practical tasks, like building a desktop app with Electron, beats anything I've experienced in Javaland. (Of course that greatly depends on what kind of projects fill your time.) I think you could argue that the way Node hops domains -- web front-end, back-end, and desktop -- fulfills a broader version of Java's original vision: to be the cross-platform language.

When a problem seems to be getting worse but it seems like not much has changed, consider that the problem used to be just as bad, it's just not being swept under the rug as effectively.

Even for doctors who express awareness of the problem with opioid prescribing, it's not uncommon to believe that every other doctor is the problem, and not themselves. Either not realizing their prescribing is above average, or realizing but justifying it with the thought that they somehow have a patient population with above average pain needs.

And yet the CDC notes that your likelihood of developing opioid use disorder rises precipitously after as little as five days on prescription opioids. https://www.cdc.gov/mmwr/volumes/66/wr/mm6610a1.htm

Regardless of whether or not this accounts for the majority of addictions, it is sufficient to say that opioids are far more dangerous for patients than many doctors believe. Addressing prescribing habits is a necessary part of a multi-pronged solution to opioid addiction.