Visiting – Epic
62 comments
·April 21, 2025neckardt
aylmao
What languages is their codebase developed in?
epicdev
MUMPS is the infamous one that pretty much everyone is at least trained in, but Epic is 99.9% done replacing old VB6 clients with C#.NET + Typescript/React. There's also developers working with iOS and Android development, and Python and SQL for data science and business intelligence.
ivraatiems
Like many here, I worked at Epic just out of college and left after a few months. Everything others have said is true. I call the campus "Disneyland for sad people," because it's gorgeous, but also totally artificial, and nobody is happy.
The one great thing Epic did for me was get me to Madison, WI, an amazing city of great people where I found a much better job and stayed for many years. I still miss it sometimes.
minimaxir
I interviewed at Epic for my first job out of college a decade ago: while the campus is indeed beautiful, the sense I got was that they were trying to emulate Google's quirkyness while offering much lower salaries (but still relatively good given the CoL) and a less exciting product domain. I'm not sure how well that quirkyness appeals to prospective applicants in 2025.
tmiku
My small liberal arts college sent a lot of people to Epic (3-5 grads out of each year's class of ~550), including me - they are known for hiring lots of fresh grads with academic-STEM backgrounds who lack tech industry experience into their technical services and QA roles. I think the hiring dynamics for those non-developer technical roles are more favorable to Epic than those for full developers, and those people tend to make up more of a company's headcount overall.
overgard
Funny story about a visitor to a game development office.
About 8 years ago I was working on a mobile game where you could purchase specialized dragons and eggs. Some of these could be pretty expensive, but since they were high end items we wrote special GPU shader code for them so they had cool special effects on them. We tested these as well as we could -- we had a room with maybe 100 or so mobile devices -- but of course we couldn't test on everything.
One day an irate older lady came to our office, and our receptionist for some reason let her in (probably thinking old lady = harmless?). Keep in mind our office was unlisted because we didn't want fans dropping by. She had driven all the way up from Arizona to Colorado (although I don't think it was the only reason she drove up), and she accused us of ripping her off, because she had bought one of these fancy dragons and instead of getting what she saw in the promo materials, its wings were black! I didn't hear or see this directly, instead it was the main topic on our Slack chat with everyone being cautioned to Play It Cool.
I didn't think much of it until I realized it was _my_ code that had caused this entire issue in the first place!
Luckily we had a really good customer service guy that defused the entire situation, but that's the first and hopefully only time I've been tracked down in person by a customer for a bug.
rezmason
Almost twenty years ago, a lady walked into my former employer, from right off the street, to ask that they unsubscribe her from the mailing list. She was in town on vacation and realized their offices were there, and just thought it'd be nice to get that dealt with in person. Especially because her attempts to unsubscribe electronically had repeatedly failed.
Almost fifteen years ago, another of my former employers had an angry customer storm into their office and start shouting at the front desk associate. Soon after they relocated, and hired a full-time armed security guard to process all visitors straight from the elevator lobby. Any further, and you'd need to present photo ID and maybe sign an NDA before he'd buzz you in.
pavlov
Epic used to be a heavy user of the legendary/infamous MUMPS programming language. I wonder how much that’s still being actively developed.
This 2007 classic explains how a case of MUMPS progresses when you’re a programmer:
epmatsw
The state of MUMPS has progressed a lot since this article was written, to the point where most MUMPS developers would probably only vaguely recognize this. Even the "MUMPS" they were using back in 2014 or so was really a higher-level dialect + higher-level framework (Chronicles) that was transpiled down to actual MUMPS. It was more like writing ES2015 + JSX or whatever and then actually executing ES3 + DOM operations.
Source: was on a team that was performance sensitive enough that I spent a lot of time in the actual transpiled MUMPS code that did look more like this article.
maxwelljoslyn
Epic is still a heavy user of that language at the lower parts of its stack, but there are other, friendlier/more modern languages in pretty widespread use too. Depends on the team & sub-application.
DaemonAlchemist
Having worked at Epic on Mumps code, I am almost certain that article was about Epic.
lvl155
The fact that Epic remains the best available solution in healthcare is quite sad. That entire industry is rotten to the core.
zdragnar
The difficulty isn't the product itself, but all the integrations.
Every small clinic wants special custom formats. Insurance eligibility providers will lie about their abilities. Some insurance companies don't integrate with any eligibility check software. Sending health info anywhere requires yet more interchange formats.
The actual note taking bit isn't too bad, and can be easily modeled with most flexible CMSs even. The problem is that you can either gamble on a startup offering everything that a company that has been in business since before you were born and actually being able to follow through, or you can just go with the established company like everyone else does.
Having seen several startups trying to break into the space, it's no surprise that epic still dominates. The regulatory hurdles alone are not trivial; clinics that take Medicaid are usually required to use an EMR with a CEHRT certification which can cost tens of thousands of dollars to obtain.
zarathustreal
It is indeed rotten, it’s a power struggle from the start. Power corrupts absolutely
DoctorOW
As a patient, I seek out MyChart because it's really well put together from my perspective. I've no idea how medical professionals and administrators feel about it, but personally I've had a great experience. I saw someone from Epic was here, so I just wanted to say keep up the good work :)
brickfaced
I've been told by doctors and nurses that using Epic sucks, mainly because you're doing constant data entry while trying to listen to and care for patients, but that it's still far better than using any of Epic's competitors.
jbentley1
I'm guessing somebody was listening to the latest episode of Acquired?
theturtle32
From their episode description: "What if we told you that the person who started, runs and owns this establishment has legally ensured that it will never be sold, never go public and never acquire another company?"
We DESPERATELY need more companies to structure themselves like this.
crabmusket
It is really interesting to hear how this was a competitive advantage for them, and certainly a product advantage. The comparison between Epic (one database for everything) and Cerner (result of like 20+? acquisitions/mergers, patchwork of systems) around the Kaiser deal puts it in stark contrast.
odyssey7
Why is “acquisition” a bad word at Epic?
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?
null
odyssey7
Why?
azhenley
Objectively the best podcast. https://www.acquired.fm/
w10-1
The significance of this to me is by contrast to most of the valley companies (FAANG and their offshoots). Over the last 20+ years, people have been trying to build a mission-oriented company with a great culture, and confident enough to build their own tools. That was the default story.
It turns out companies are transient or have been internally infiltrated by such (outsourcing- and ambition-driven) politics that any mission is more supplement than reality, and there's no sense of controlling your own destiny.
So perhaps the dream persists out in the tech boonies in the ultra-sticky EHR domain, goosed by the Obama/insurance mandates to digitize, where developers are trapped by unportable skills. (Or perhaps in smaller B2B companies filling a niche.)
robertclaus
I would say Judy is far too pragmatic to fall into the bucket of late 90's silicon valley startups. For example, people talk a lot about MUMPS being so quirky for the Epic operational database, but few people mention that Epic is a heavy Microsoft shop and ALSO provides a reporting SQL data warehouse built on SQLServer.
shigawire
If you said they were using a NoSQL database since the 70s, HN would think it was cool.
hiAndrewQuinn
My first post-college job! Nothing but good things to say about it, all my colleagues were whip smart at what they did. I especially liked the interview process, where I had to do a couple of standardized tests online to prove I was in the top x% of test takers. Given that I had to lock down a full time job as fast as possible after college it was a real time saver to just be able to demonstrate objective general competence like that and move right on to the interesting stuff.
starfezzy
> take an IQ test, skip the BS, work with highly intelligent people
This is the way.
weitendorf
I did an internship at Epic and didn't fully appreciate it at the time, but I think their CEO Judy might be one of the best tech/general leaders ever.
Epic has a reputation of hiring lots of new college grads. For software engineers that's not exactly uncommon, but Epic actually has a lot of employees working under titles like technical solutions/implementation solutions (or something like that): the people directly supporting the hospitals using Epic. Because these are pretty specialized roles, Epic has a very formal and fleshed out training program for their new hires with classes and courses and such, and it can take months to complete. They not only have their giant campus in Verona, they have an entire training center there, a huge auditorium for allhands, and a very streamlined recruitment process (for a ~21 year old it feels over the top luxurious). Although Epic does hire from more selective schools it seemed the majority of their new employees are from state schools in the Midwest.
They also are private despite their size, just basically don't do M&A and are, relatively speaking compared to other big corporates/tech companies, in the middle of nowhere.
In corporate America this is a highly unusual way to operate. I think it's underrated how big of a "risk" all these heterodox corporate strategies are for an executive and it speaks to amazing ideation and execution on Judy's part. Also, even though Epic does have a decent amount of turnover, she has taken a chance on tens if not hundreds of thousands of young people who didn't have the skills she needed them to have already, by giving them months of training and a really solid start to their careers.
robertclaus
I've long since moved into startups, but Epic was a great place to learn process and the less technical aspects of enterprise software development. The tech has modernized a lot in recent years, but still isn't transferable quite as easily as other tech companies - but that legacy means it's an amazing place to learn the why behind best practices.
My first job out of college was working at Epic on MyChart. Great people, terrible code.
Epic’s main problem is a lack of clear internal code ownership. Everyone owns all the code. This means that even if you clean something up, someone on the other side of the company may come in and mess things up again.
This led to really defensive programming where developers would never refactor, they would simply add a new if case for their new functionality somewhere deep in the code, then prop drill the data down. This led to every core function having over a dozen parameters and hundreds of branches. It eventually became impossible to reason about. Cross team calls were just function calls rather than defined apis. This made it fast to develop code initially, but terrible to own long term. This mainly applies to their Mumps code.
While I was there I felt like Epic was beyond saving, but with a big push there may be something they can do:
1. Enforce some level of code complexity. Best practice is 40 lines per function and no more than 4 parameters per function. Epic probably shouldn’t shoot for that, but a 100 line limit and 6 parameters per function would already be a huge improvement.
2. Enforce strong code ownership. Epic has many people who are there for life, let them cook. Epic should segment off code to certain teams so those owners can fix it at their leisure. Cross team api calls should be clear API contracts. It would require some more discussions to get feature requests approved since not everyone can do anything anymore, but the code would gradually improve.
Epic is too important to fail. I hope things have started to improve since I left.