Epic Systems

Culinary is amazing, and coworkers are almost always pleasant.

The pay for software developers is pretty good, but you're definitely going to fall short if you're in the 1%. Nothing compares to one of the coasts in that respect.

I actually think the work/life balance is okay, but I think the job in general isn't very hard. YMMV.

Your direct team lead is often competent; however, there's definitely some turds in the punch bowl. Getting rid of a bad team lead often requires a huge amount of effort.

Unlike others, I actually find the average quality of developers to be quite bad at Epic. We aggressively hire kids fresh out of college, and our hiring bar seems to be quite low. As a result, some teams have dumpster fire code bases. It's a complete crap shoot whether the team you end up on will have good coding style and a reasonable code base. I've worked on open source projects and for other companies, and Epic has by far the worst code base I've ever seen. It looks like this is probably trending up over time.

The company is heavily driven by process. Getting work done is often very hard because of the process. I'm often either fighting the process or doing my best to subvert it so I can actually get stuff done.

Working with customers is often frustrating. The huge demand for health IT workers has led to customers hiring woefully inadequate employees. Doing your job often means holding customers' hands and doing their job for them. Couple that with childishness about timelines and issues, and you have a pretty poor experience.

The technology stack is gaaaaaawwwwwddd awful. The homegrown web frameworks are hot garbage. VB6 is still heavily in use. Also, we've switched our recommendations for what to use in the language stack multiple times over the last 3 years. As a result, even brand new code uses old standards almost immediately after it's wrapped up, and our 'new' code base is a mishmash of multiple competing frameworks, libraries, styles, and languages. Context switching takes up a huge amount of time. It's like we took all of the worst parts of micro-services and shoved them into a monolithic code base. The system 'architects' making decisions for the company seem to just be throwing darts to figure out what cool new thing to jump on to next.

On the web side, you do at least get to use C#. On the server, you use MUMPS or a TS to MUMPS transpiled language, which further creates confusion. I actually like using plain MUMPS. That's not a popular opinion, but the average developer doesn't seem to actually know the language despite how crazy simple it is. Speaking of, several language features have been deemed off limits because we can't expect the average developer at Epic to do it right. You're quite literally held back by your coworkers.

Epic eschews a lot of benefits common to other technology companies, such as flexible working hours and locations. Despite the shtick about flexible hours, it's been my experience that it's a lie. They expect you to be there from 9-4. Deviations result in negative feedback. If I remember correctly, the core working hours used to actually be officially written in the internal company handbook, but they took them out a little while ago. Based on my experience, this wasn't done to make it easier to work flexibly; it was to allow managers to inconsistently apply requirements.

While lower-level management is often competent, upper-level management is completely out of touch with reality. Getting into upper-level management seems to require fanatical devotion and unquestioning loyalty. The punch is very good indeed.

Decisions are made capriciously, regardless of how far-reaching they are. Process is blindly followed and applied without thought. Speaking out against blindly following process is a sure-fire way to get in trouble. It's also a tremendous waste of time. Blindly following process is heavily encouraged at all levels, which creates some blindingly frustrating scenarios where we do the wrong thing because the process demands it.

Recent decisions surrounding working from home have made it very clear that the needs and safety of employees is a distant second to productivity and company culture. This is especially frustrating given that all the quantitative data I have access to actually says productivity for R&D has gone up since working from home began. The takeaway seems to be that sacrificing employees is ultimately worth it to avoid some perceived loss in company culture that we can't describe or track with data. A company call reinforced this; upper management indicated that 'data doesn't tell the whole story, and we'll never be able to quantify the loss from working from home'. TL;DR, we don't care about your data; you're coming back whether you like it or not. You won't change our minds.