If you notice a company lie while recruiting you, when should you expect them to start being truthful or fair? What other lies might await the candidate?
This defense of Epic really makes it sound like a great opportunity.
> I also think their employees might overestimate how much greener the grass is on the other side, because they haven't actually experienced any comparable job
Many people continue to regret their time at Epic even after having left and having seen the other grass first-hand.
> Personally I think Epic actually does a pretty good thing training up and employing so many new grads with skillsets that don't find it as easy to get solid corporate jobs as SWEs
Count the MUMPS training to essentially be a waste of time, unless you like the idea of writing MUMPS going forward.
Also, your endorsement reads as if Epic should be an option of last resort rather than a place where a software engineer should want to be.
Is it because the workers at a normal company would jump ship if Epic’s culture were imposed?
If companies like Cerner, Google, Apple, Microsoft, etc. are all able to acquire and integrate software that was initially developed by others, why not Epic? Surely Epic is not less competent?
Epic has a pretty unique way of doing things in corporate america (maybe not that unusual for big tech companies, but very unusual for healthcare and general corporates) and I think acquisitions would cause them a lot more trouble than they'd be worth. For example, Epic has one giant HQ campus where they do actual-allhands in giant auditoriums and a really extensive training program with onsight classes and IIRC an entire massive building for it.
Technically speaking I think they see buying software + changing it to be more like Epic (or continue to operate/develop/support it independently) as a waste of money when they could spend that time/money on improving what they already have.
I also think it's probably a branding/marketing promise to their customers that if you buy Epic software, you're not going to have that contract morph into one with some other generic corporate company who causes problems trying to integrate/migrate your setup. Nor will you have wallstreet begging Epic to juice their customers for all their worth just because they might get away with it and it'd make the stock look good temporarily. (I have no idea how expensive Epic is comparatively but I do know EHR is very difficult to migrate from and Judy is known for playing the ultra-long-game).
I think basically the idea is that acquiring another EHR vendor would only be for the benefit of expanding Epic (the company) market share but detract from making Epic's software a better product for their customers.
> able to acquire and integrate software that was initially developed by others
I can't tell you for sure, but the way it was pitched in the recent Acquired episode on Epic is that no, they* aren't able to integrate software from acquisitions well.
Without knowing this in detail, it sounds like the choice is between one system that does everything, and a patchwork amalgamation of systems, databases, UIs, which are not well integrated.
I can't say this for any kind of fact; it's just the impression I get. It seems highly plausible to me.
They touch on this in the episode and there are myriad reasons.
One interesting one is vertical vs horizontal software dev. Epic's advantage is deep domain knowledge of healthcare (relative to competitors at least - a Dr or nurse will dispute that lol).
At Google, Apple, Microsoft they want to make software for everyone. Epic hyper focused of their niche and has decades of knowledge built into the business logic. It's also why the aforementioned companies have failed to take a piece of the EHR market despite more technical knowhow and huge war chests.
Lastly, Cerner is a bad comparison since Epic ate their lunch over the years. If anything it might be a data point that their approach is poor. Cerner rev cycle still doesn't work and Oracle has said they are scrapping the product they spent $28B on.
Epic's design philosophy from the beginning was "one patient record" for the whole hospital. Everything being well integrated has been a standout feature over the competition for a long time. An acquired product would have to be rewritten to work with the database. And since healthcare is such a dense field, a new product is more than just code, it's also domain expertise which would need to be integrated into the company.
Since Epic has good relationships with its customers, working with them to build that expertise from the ground up is considered better.
Do you remember writing the proof for quicksort, which is say 0.1k lines? 15k lines of verified code is a pretty good indication of effort.
But the problem may come from the headline, which is somewhat clickbaity. HN forbids changing it, and then part of the discussion focuses on the literal content of the headline, which is, as you rightly hint, not the best summary of what's interesting here.
> A 15,000-line proof is going to have a mistake somewhere.
If this proof is formal, than it is not going to. That is why writing formal proofs is such a PITA, you actually have to specify every little detail, or it doesn't work at all.
> Verifying that those 15,000 lines do what they do doesn't give me much more confidence than thorough unit testing would.
It actually does. Programs written in statically typed languages (with reasonably strong type systems) empirically have less errors than the ones written in dynamically typed languages. Formal verification as done by F* is like static typing on (a lot of) steroids. And HACL has unit tests among other things.
Radiographer: “MRI (magnetic resonance imaging) creates detailed images of the inside of the body using strong magnetic fields and radio waves, rather than X-rays. MRI is/was the holy grail for medical imaging professionals. Arguably the coolest images come from MRI”
In my case, I had a lung issue and CT scans are more sensitive to air being where it shouldn't be. At least two of the 5 ct scans could probaly just have been x-rays tho.
Largely agree, but still very much depends on what you're screening for. For example, my oncologist still recommends CT over MRI for post-surgical screening as the increased resolution makes it possible to detect tumors a bit earlier.
I’m not familiar with the parameters of the machines readily available to your provider, but I can say that the risk/reward scenario for an intervention for someone coming out of cancer surgery is distinct. We give cancer patients chemo and radiation that we would never give to someone who just showed up in the ER or was still undergoing preliminary diagnostics.
reply