The Passion of Epic

Contents

• My Day
• Foundations GUI
• Chrontrol
• A Different Kind of Focus
• At Home
• Passion
• Crossroads

Many many years ago, in a building and fantastical land far far away, I enjoyed my job every freaking day.

Every day. 100%!

I worked LONG honest hours. Days not filled with meetings and going to long lunches and chatting up everyone about anything. It was work. Challenging new work. It tickled all the right parts of my brain in just the right cognitive ways.

It’s interesting that as I reflect on that period working at Epic and how that passion ebbed and changed over the decades and that even recently, working on my own I found that same energy again — multiplied beyond what I experienced in those early formative Epic years.

My Day

An average day back in 1996-1998 for me was as follows:

1. Wake up about 5:30am
2. Shave, shower, eat breakfast. Pack lunch.
3. Leave my apartment around 6:45-7:00am
4. Arrive at Epic about 10 minutes later — there were plenty of underground parking stalls available at that time of the day (about 7:15am).
5. Work solid till about 7:00pm.
6. Return home, eat, do more programming and watch a TV show.
7. Sleep.
8. Repeat.

I didn’t do that on weekends very often as I did need a bit of recovery time and had things I did need to do — generally mundane things like grocery shopping, laundry, exercise, cleaning, etc.

And honestly, looking at it as a list like that — it might seem tragically boring and full of missed opportunities to many of you I suppose. I hadn’t met many new friends — so zero meaningful social life, and the reality of it was that I enjoyed doing different things than many of my friends at the time. They went to work and then wanted to disconnect from “technology” and programming.

I have some moments of envy for adults at a similar age today with their modern tech that would have likely filled evenings with video games and other distractions, but they’re only fleeting moments. I like learning more than I like “play.”

During that period I was leading a small team creating new building blocks for the next generation of Epic applications. We were creating components and frameworks for a new Visual Basic 5 based Foundations library. New Epic applications would use the framework to build their applications and older applications would start to migrate and use what they could from the new code base (which seems funny saying now as no GUI app was older than 4 years at that point).

Foundations GUI

The project didn’t have a fancy name. No fancy logos. No marketing department.

It was Epic, so none of that should come as a surprise. Back in 1996, there definitely wasn’t a marketing department. We literally added “GUI” to the Foundations team name. 🤣

We weren’t exactly starting from scratch. There was some precedence for the work established by the few teams that were already using Visual Basic (see EpicCare/Legacy/Cadence). Most of the code wasn’t usable though in a component model and couldn’t be distributed as Foundations code without minimally moving it to a Foundations namespace.

MUMPS routines at Epic were grouped by application, using one or two leading characters to indicate the originating team. It wasn’t a perfect way of organizing code, but it was effective enough and reasonable to manage. The new code we were creating would need to be E* which was reserved for Foundations (in addition to a few special “system” level routines starting with %Z. )

At first I think we were all a bit naive about how complex it would be to build a Foundations GUI control set that applications could use. That naivety kicked us in the project plan not too long after.

No rosy pictures were painted for my manager at the time, wholly indicating that we’d work our butts off, but there was still a monumental amount of work that needed to be done. Think scaling Everest, not just minor mountains like Pike’s Peak.

The application code really wasn’t designed for reuse and had not included many features that were core to the Foundations database Chronicles. No fault to them — they built the features they needed only, nothing more.

It wasn’t feature complete and had too much functionality that was not designed for scale. So, while some code was copied for a quick win, 99% of it was rewritten. At scale, it just needed help to handle a larger variety of uses than it was originally designed for and at the same time we introduced a number of performance optimizations and learnings. We were generalizing the code and adapting it to a much larger set of functionality.

Further, there were a significant amount of connections in the code to the Electronic Data Interchange (EDI) team and a number of their databases (AI*). That code and implementation was one of my least favorite parts of what EpicCare had built. It was … bad to put in mildly.

Chrontrol

After some debate, we did decide that a few of the controls minimally needed developer “fun” names. Not many stuck, but the entirely original Chrontrol was one of the favorites. The Chrontrol represented a single value of any supported Chronicles type (single response for those of you keeping track). It included the ability to do most everything that a screen paint entry field could do. Basic text entry to dates and everything in between. It turned out that — well, it was extensive. Nothing like taking 17 years of development at Epic and cramming it into a new platform in a few short years.

Frustratingly, a tremendous amount of code in Chronicles made an expected but unwelcome choice. It frequently manipulated the terminal device. Like, OH MY JUDY, code was often littered with the expectation that there was a terminal device that could be written to at any time.

Why was that a problem? Because the communication protocol back in the 1990s used TELNET. Refer to MUMPS command for more details. Since we were adding this functionality to Foundations having copies of Foundations or application code wasn’t desirable at all. Instead, the team needed to walk through each block of code, every tricky programming point, everything … to look for unexpected IO and decide whether it needed to be conditional or eliminated.

HOLD UP!!. Before you think walking/stepping through code wouldn’t have been too bad — THERE WAS NO DEBUGGER. So, “stepping” through code was either manual or had to output tracing to globals (as writing to the screen was obviously off limits).

I’d like to say we caught them all through just a code review. Some may have been left unintentionally behind.

Thankfully there was a tremendous amount of testing and use before any code left the building. It wasn’t infrequent especially at first that we’d encounter or get a report of some issue with IO. It wasn’t always Foundations code, but we investigated each one. Fun!

No. Not fun. Satisfying when solved, yes.

You may wonder what drove my passion during this time.

Challenge, Curiosity, and Creativity

What we were doing wasn’t easy. It wasn’t straightforward. It pushed the edge of Visual Basic 5 beyond what I know Microsoft was expecting and intending (I later had some conversations about just that — many Microsoft developers on the Visual Basic teams were “impressed” by what we’d done with their tool).

We weren’t just building a component library. We were establishing new APIs on the client and the server, exploring the often mind-boggling experience that was Windows 95.

We divided up the work with a huge amount of overlap. I took ownership for what was soon to be called ChronGrid. The team did a remarkable job building and testing the new Foundations GUI.

The ChronGrid nearly broke me multiple times. SNAP. CRACK. POP.

The challenge pushed me along though. Some days were certainly a drag: bug, missing feature, missing feature, missing feature, bug, … As I was applying so much new knowledge of the internals of Visual Basic 5 and pushing the Windows API to bend to fit our requirements, I stayed on track.

Weirdly, many of our user experience requirements were driven by functionality of Chronicles Screen Paint and basic text interfaces. While I suppose that may sound ludicrous to some degree, the workflows and efficiencies built into applications were in part key to their successes. Functionality was important, but the performance of workflows was elemental in Epic’s infrastructure and application designs. Watching an appointment scheduler zip through a text based scheduling workflow was very motivational.

It was an interesting conundrum in many ways. How to make rendering hundreds to thousands of rows of one to dozens of columns (related groups for those who continue to keep an Epic score), with each cell having customized rendering based on the core type and configuration — that was a lot. Heck — there are many modern JavaScript based grids that can’t do that well on modern hardware using all the latest tricks. Having just written part of a virtual grid in JavaScript late last year for a project — it’s not easy. Remember — these computers that Epic customers would have been using would be considered “retro computing” these days. We achieved often stunning results I think that were frequently underappreciated as it was just expected that the delivered products would be as fast as possible.

It was more than a lot for the Visual Basic 5 platform and Windows. Many common interactions with the UI and standard patterns simply didn’t behave the way we needed.

What was frustratingly interesting about Windows APIs at the time (and for many decades later), managing the user input focus was a Jurassic Park sized pain. It was as if: the Microsoft developers didn’t have experience building enterprise applications. Huh.

A Different Kind of Focus

The APIs lacked precision and fine grained controls. There were two core issues:

1. When the input focus was moved to another field either through keyboard control (like the tab key being pressed) or using the mouse, there was no way to prevent focus from being lost by another control. The newly focused control would get focus before the previous control lost focus — there was never an indeterminate state of “nothing has focus.” This meant that input fields such as the Chrontrol might be invalid for the moment. While that might seem OK — it wasn’t as there were often dependent fields in a workflow. The next field might change or disable based on another field’s yet to be validated user input. This meant that the input was bouncing around (faster than the eye could generally see), but it was happening.
2. Controlling tab order within a control like a grid was … fun. For the Grid, it meant that there were actually 3 input fields, two off screen and one primary editor. The ChronGrid couldn’t create instances of actual Chrontrols without quickly depleting all GUI resources available in Windows. Instead, it hosted one control instance and kept resetting it based on the current cell. But, to manage focus, there were two inputs as I mentioned. One for “forward” and one for “back.” Depending on the state of the grid and settings, one or both of these hidden inputs might be enabled. When the user tabbed forward, if the “forward” input was enabled, it would briefly get focus and in doing so trigger the grid to … do one of many many things based on the current configuration of the grid. For example, add a new row or move to the next column in the current row.
3. And as a bonus: many Chrontrols were matched to database values for category (pick lists) or database records (like selecting a medication). When the user typed in some part of the name and tabbed away, the app needed to immediately confirm that the field was valid and retrieve either the exact match or the list of potential matches for the user to select from. The user experience desired was that no field would be left invalid.

One frustrating hold-over from text based applications was that in most workflows the tab and ENTER keys were accepted as a way to move to the next field. For a brief period, it was a hill I was willing to die on: eliminate the ENTER key as navigation as it was very non-standard (and still is today). The applications weren’t behaving like other Windows based applications. I stepped off the hill eventually, it wasn’t a great experience, but I conceded I didn’t care enough to continue the argument. It was also a common source of bugs when developers failed to account for it. Remember — this was non-standard behavior, so Windows had zero support for the behavior. The ENTER key behavior made more sense in the grid, but not other fields.

The team really excelled at that time — churning out great code and consistently delivering. If they read this: You Did Great Work.

At Home

After this intense period I found that I transferred the passion from being “on the job at the office” to the home. 80% of my hobby and evening time was all consumed by projects and experiments directly related to Epic projects and needs. It was just on my own time with no time commitment. In some ways it was perfectly freeing as I chose my path and could explore without concern of misusing Epic “on the clock” time.

Passion

Was the passion repeated at Epic? I had a few more periods working on very interesting projects both short and long term, but rarely as intense and all consuming. It wasn’t age or maturity. I did my best with the hours I spent. Weirdly, I think I wasn’t working on big enough challenges. I craved that.

What’s been great in the last year is that I rekindled that same energy in several projects — multiplied beyond what I had even back then when I was … ah … much younger. I’ve found myself doing 8-10 hour days 6 or 7 days a week, driven by this same nearly insatiable quest for knowledge.

Crossroads

I’m at a crossroad right now though, deciding what to do next and looking for the next opportunity.

I’ve got several options, but none at this point are lighting the fires that translate to a longer term passion that I’d like to rekindle.

If you have opportunities or suggestions, please send them!

Are you energized by your job? Are you being rewarded for that energy?