I had the hugest of headaches. I needed something to dull the pain so I could keep working.

I’d been staffing the Epic “booth” at a conference in 1995 or early 1996. I’m embarrassed to say I can’t figure out what conference it was though! It was much larger than my TEPR experience. I found a “history of HIMSS” document and confirmed it wasn’t a HIMSS conference. In any case, I was there to answer technical questions about Cadence / Epic and deflect non-customers from the booth. There were a lot more Epic staff on hand — it was an important conference.

We were staying at the Marriott Gaylord Opryland Resort & Convention Center in Nashville, Tennessee (USA). It is absolutely bonkers of a hotel and conference center. Take ALL of the ideas you might have about what you’d want in a hotel experience and that idea was likely manifested somewhere in the facility, if you could find it. I’ve stayed in hundreds of hotels (from theme parks to Vegas to a former castle in Ireland) and never stayed at somewhere that had so many things going on — it wasn’t relaxing — think MORE COWBELL.

From the Opryland Hotel web site:

“Inside our airy, nine-acre glass atriums inspired by the vibrant energy and charm of the region, you’ll find winding waterways, lush gardens, and an enchanting atmosphere. Wander through the tranquil paths, find a quiet spot to chat, or simply relax and enjoy the perfect 72-degree temperature.”

If you’ve been on business trips, especially Epic trips “back in the day”, you’d visit cities by arriving late at night, do a thing for 12-16 hours, sleep and then wake up for an early morning flight. That was my first trip to Nashville. There probably was a city, but I arrived at night and left before dawn two days later. I only went outside to get from the airport to the hotel. One of THOSE trips.

There were two things I remember from the event. First, being a booth guard. There were thousands of attendees at this conference (still frustrated I can’t figure out what the name was!!!). There were many competitors and consultants that would attempt to watch demos or ask questions about our software. On more than a few occasions I had to Midwest Nicely ask someone to leave the booth.

The most frustrating one was a former Epic employee that had become a consultant for a competitor. He kept coming back to the booth and trying different avenues to learn about software release dates, etc. Under the guise of “friendly ex-employee asking innocent questions” he tried and tried. A little part of me felt bad for him that he’d decided to do that. But, a bigger part was surprised that he thought we were gullable enough to fall for it. There are often “pre-huddles” either at Epic or before the conference floor opens to visitors where last minute topics are discussed. He’d been a topic of both meetings as a warning.

I’m sincerely glad my career hasn’t required me to be on the opposite end of that.

In the middle of the afternoon on day 1, my brain hurt. I couldn’t concentrate and desperately needed some medication for a pounding headache. The cold and dry conference center air with the noises, the crowds, dehydration, talking to people … HEADACHE. I’d finally decided to try to find my hotel room (which was an adventure itself) and get something for my headache.

As I was just about to leave the main exhibitor hall, Judy saw me and asked how I was doing. Yes, she knew my name. 😀

I told her it was going well other than the pounding headache I’d developed.

She said “hold on!” and began to shuffle through her handbag/purse. A moment later, she offered me two ibuprofen/aspirin/what-evers. 99% of the time I would have declined that offer from nearly anyone (as I’m a no-double dipper, wash your hands, germ-a-phobe), but the gesture was so unexpected and my head so pounding I accepted them graciously and eagerly and used what little water I had left in a water bottle to swallow them immediately. I of course said thank you and I don’t think we chatted further.

Your two take-aways from this post:

• Don’t be the person who tries to get ex-coworkers and friends to tell you secrets
• Judy gave me drugs (yes, OTC drugs, but still).

If anyone knows what conference this would have been, I’d appreciate knowing and will happily update this post with information.

I wanted to periodically grab a snapshot of the mainline/default branch of every repository on my locally hosted Forgejo Git server. I wrote the script below for Node 20+. It has no external dependencies. It’s not fancy, but it works for me.

Save it as a .mjs file (or use node --input-type=module scriptname.js).

You’ll need an Access token to grant the script privileges to scan your repositories and download the primary branch.

• Go to your user’s access token Settings > Applications > Access Tokens
• Then, provide the token a name (it’s just for your notes).
• Select repository permission: read
• Select user permission: read
• Add your username and token as shown in the script.
• Change the GITEA_HTTP_SERVER to the name of your git server. Mine is called sourced in this example.
• Repeat the process for any other users you want to add.

Then, start the script. It will download to a subdirectory called repos/{username}. Or, you can modify the script to save to another location.

import { writeFile, mkdir } from "node:fs/promises";
import { Readable } from "node:stream";

const GITEA_HTTP_SERVER = "sourced";
// PUT the user name and an application token in the array of arrays:
// It might look like this:
// [  ["acorn", 3bd876af5a5629c31982900cd4f8956a469cccec" ]]
const TOKENS = [["username", "access-token"]];

async function getRepoNames(name, token) {
    const response = await fetch(`http://${GITEA_HTTP_SERVER}/api/v1/user/repos`, {
        method: "GET",
        headers: {
            Accept: "application/json",
            Authorization: `token ${token}`,
        },
    });
    const repos = await response.json();
    return repos.map((repo) => [repo.name, repo.default_branch]);
}

async function downloadRepo(username, token, repoName, branchName) {
    const response = await fetch(
        `http://${GITEA_HTTP_SERVER}/api/v1/repos/${username}/${repoName}/archive/${branchName}.zip`,
        {
            method: "GET",
            headers: {
                Accept: "application/zip",
                Authorization: `token ${token}`,
            },
        }
    );
    if (response.ok) {
        const stream = Readable.fromWeb(response.body);
        await mkdir(`./repos/${username}`, { recursive: true });
        await writeFile(`./repos/${username}/${repoName}.zip`, stream);
    } else {
        console.error(`Failed to download ${repoName}, ${response.statusText}`);
    }
}

for (const [name, token] of TOKENS) {
    const repoNames = await getRepoNames(name, token);
    for (const [repo, branchName] of repoNames) {
        await downloadRepo(name, token, repo, branchName);
    }
}

The first healthcare conference I attended was TEPR sometime in 1995. TEPR was of course an acronym for Toward an Electronic Patient Record. I was on the Cadence GUI Team at that time, but the sales team wanted to show Cadence and EpicCare Ambulatory to the TEPR audience. Attending the conference meant we’d have an opportunity to see what else was out there, and honestly, have a look at the competition. We’d staff the booth for some of the time by answering questions and redirecting competitors away from the booth.

While I’d been to Florida as a child (Disney World), I’d never been to the “East Coast” of the United States. The farthest east I’d been besides Florida was Ohio. The experience was definitely new for me, and while Introvert Aaron was not entirely enthused about staffing the Epic booth, seeing what others were doing seemed interesting. I can’t find the old schedule for exactly when and where the TEPR conference was held that year. Since the Medical Records Institute folded in 2009 (the organization that hosted the conference), the data may be lost to memories only.

In any case, Washington DC here I come!

The conference was two days, and I was arriving with another software developer on the Cadence GUI team. Our team leader was to show up later as he was on a sales trip and wasn’t flying directly from Madison as we were. Our schedule was to fly in the early morning and leave the next day afternoon.

As you read further, this was 1995. Cell phones were luxury items. Paper maps were all the rage. AOL was the way we got online. We had no laptops (or computers of any kind with us). We had no access to our Epic internal communication system.

After checking in, we got all dressed up and headed to the convention.

🤣

I assume many of my readers have been to the Epic campus (either as an employee or as a customer). Voyager Hall, the training facility has meeting rooms that can seat anywhere from 50-250 people depending on arrangement. They’re large, but not huge by any means. Or, if you’ve been to HIMSS and the Epic booth, I’d guesstimate the current Epic booth was about the same size as the entire conference floor.

TEPR 1995 would have fit into the Epic HIMSS booth.

Needless to say, we were not aware of that before we set foot in the exhibitor hall. This would have been Epic’s first time exhibiting at this conference so our expectations were much grander for the size of the conference and the number of attendees. There were maybe 50 exhibitors TOTAL. We walked around for about 20 minutes at a very slow pace looking at the vendor names and gathering a rough understanding of what was being exhibited. It was underwhelming. There were no educational sessions for us to attend. It was essentially the exhibitor hall.

However, what was more confusing: we couldn’t find the Epic booth!

After a tiny bit of checking: it wasn’t that we needed a map. We’d actually seen the booth several times. It was the booth that had a folding table set up with two chairs but no one there — that was Epic’s booth. The salespeople hadn’t shown up!

Surprised — we decided to call back to Epic. What’s funny is that I don’t remember how we did that. We were discouraged from using the hotel room phones as their rates back in the 1990s for a long-distance call were HIGH. Like, someone is getting rich high.

What we learned: the sales team was delayed and still planned on showing up. Our TL was on his way and would be arriving later in the evening (he was already on the plane). After relaying the poor attendance and lack of vendors, it was decided that sales team would not show up at all. We enquired briefly about alternate flights, but … remember, 1995, it wasn’t something that was easily done quickly (and we had no access to the agents).

We decided we’d make another pass through the floor, talk to whomever would listen and then wait for the TL to show up.

Honestly, that took no more than 45 minutes before it became completely obvious that spending any more time on the convention floor was pointless.

We were at a loss for what to do. It wasn’t like we could just work remotely — all we had was a pen and paper for notes.

Note: SEND HELP.

I like doing software development, but I wasn’t going to try to hand-write code! We also didn’t have any compelling designs or anything to talk about.

Hmmm. Washington D.C. may have some things to do.

We went to the front desk of the hotel and enquired about seeing the city. They had a tourist map, provided some basic instructions and said the subway was the best way to get around quickly. We had about 4 hours till our TL was to arrive.

We quickly changed and headed out. We found a subway entrance nearby and asked the super friendly agent about tickets, getting around, safety, what to see, … they were amazing! We’d explained how we had limited time, new to D.C., etc. and as it was at an odd time of the day, we were the only customers.

Off we went. We saw more of D.C. in those 4 hours than I think should have been humanly possible. It was AMAZING. For those of you keeping score: it was during a work day on Epic work hours. The SHAME! (We sincerely wanted to be working, but there was no work to do!)

We got back to the hotel very shortly before the TL arrived. After explaining the situation, he called back to Epic and we learned that changing flights was way too expensive, we’d already paid for the hotel stay …, so coming home early wasn’t an option. We had dinner at the very overpriced hotel restaurant and made plans for the next day. He’d go walk the convention floor briefly and then … we’d do a rapid tour of D.C. with him. 🤓

Our fearless TL wanted to see some of the same sights we’d visited but we also took a closer look at the United States Capital building. There were two funny events that happened there.

First, CNN was filming live about something. Our TL wanted to get in behind the shot and wave. He did. Maybe on some archive footage of CNN on a VHS tape you’d see him waving … but not me. We stayed back (we had great fear).

Secondly, we wanted to go in the Capital building. There was a long line though. It wasn’t “security” as much as it was just basic crowd control. We didn’t have time to wait in line, so we wandered around the Capital building instead disappointed by the line. There were a few doors … and one that didn’t have anyone there watching it. We walked up, checked it — OPEN! — and went in. We essentially used a “back” entrance!

I may be exaggerating, but my feet felt like we did 42 million steps after those two days and I recall how painful my feet were for several days afterward. But, the experience was worth every step, even seeing the same sights twice. I didn’t have a camera as I hadn’t expected to do any sightseeing while we were there.

What conferences have you attended that you fondly remember because of the work you didn’t do?

Overstaffed with newly hired software developers on Cadence, the small Cadence GUI team had to adjust to the economies of doing Epic business.

The Cadence development team had approximately doubled in size and simply did not have enough experienced developers to maintain a high degree of software quality. In fact, the quality had noticeably dropped. New code. New bugs. It was a runaway train … of bugs (yuck!). Of course, it wasn’t really the new developers’ fault — they were new and the code base was already quite large and very complex in many functional areas. The environment was stacked against their success unfortunately.

Using a Midwest cow 🐄 analogy as is common with Epic — the area that was fenced off for Cadence had unfortunately a massive number of cow-pies you could step in. (Cow pies = 💩 for those not in the know.)

There wasn’t much documentation to help them either. The code was … shudders … the documentation. It was a ruthless enemy of knowledge. MUMPS code can be a real chore to follow and debug, especially with the ability to extend workflows with customer driven code extensions (we called them “programming points” for many years). Cadence used these extensions a lot in some workflows.

Programming Points used in Chronicles Screen Paint added a whole new level of “whaaaa???” to projects.

An basic example of these programming points in use could be when an appointment was scheduled. When that happened, custom code, either written by Epic for a customer, or by the customer directly, would be executed. An appointment might trigger an interface message to another software system or print a label, or … Whatever was wanted! It literally was just a placeholder for “execute anything.” There are better design patterns for creating functionality like this today, but the Epic solution was functional and worked within the MUMPS environment. The often frustrating part of the programming points was understanding what their side effects might be and what expectations programming point code might have. They weren’t documented well. To be clear, the level of documentation these programming points received was often better than what other external systems and products were doing at the time (which was generally little to nothing), but we hadn’t delivered something remarkably better either. It would have great if more boundaries had been clarified for sure.

To further add complexity to these programming points, it was uncommon for Epic to have access to the code used at customers (and especially in a live/demo/testing environment).

While there were a number of starter projects for the new hires, each project required more attention for design, programmer review, and testing than they had been getting. The team had experienced developers and were generally very trusted to commit good code, so code reviews and testing were light generally. But, the new round of hires changed everything.

A choice was made in a meeting I wasn’t invited to attend. I would have needed my perfect poker face at that meeting to not express my true feelings. It’s better that I hadn’t attended as I doubt I could have maintained a “rah rah” attitude.

In this meeting, it was decided that Cadence GUI software developers would spend no more than a 8-10 hours a week on GUI and the rest was devoted to code review and testing. Ugh!!!

While I absolutely understand it was a necessary outcome as a positive Epic business decision, the impact on my personal happiness was profoundly negative. From daily new challenges of building Cadence GUI to a slog of reading MUMPS code and trying to interpret not only code that was often new to me, but trying to understand whether the code was the right choice was draining. Day after day after day.

And day after day. After day.

As has been a common Epic theme over the decades, Epic had committed a lot of functionality for sales and customers and the results was a massive backlog of development that was contractually committed for the next release cycle. While I’m sure the senior developers could have completed the work faster and with fewer issues, it would have been a terrible disservice to the new hires and our future selves. We threw them into the fire. This was a period were we had few fire extinguishers as well. Many fires needed extinguishing. We needed the new hires to learn how to prevent code fires earlier and that required us to adjust.

The days continued. This period went on for about 3-4 months before I’d reached my breaking point.

You’re probably thinking that I was impatient. Yes, about many things I’m terribly impatient (don’t ask my wife!!!). When my mind goes into boredom mode, my enthusiasm shuts down. My itch for creative outlets becomes the focus of any idle time (and often distracts me from the task at hand). Being allowed about a day a week to work on Cadence GUI was a tease in many ways. Little got done as it was difficult to start and stop something that was so fundamentally different from the quality assurance work. Context switch. Context switch. GUI! Context switch. I’m sure my hours worked went UP during this period so I could work more on the thing that was excited about (sad, but true).

I’ll be interested to hear what others think — is the ability to shift resources for short term crises like this a strength or a weakness of Epic culture? The number of times that something comes up and a human is tasked at Epic to do something else for some period is uncountable. Emergencies — sure. But, what about when the reason is poor planning?

I could draw a lot of squiggly lines on a whiteboard that would eventually connect to demonstrate why I found myself back in Carl’s office at the end of this period asking for a new team or project. It turned out — there was a need elsewhere as EpicCare Ambulatory had outgrown Visual Basic 3 and Windows capabilities, so there was work that needed to be done. They had dug themselves a large hole with their design and implementation that ran into unbreakable limits within Windows 3.11 and Windows 95.

But, that’s a story for next time.

Thanks if you’ve subscribed to my newsletter! Every subscriber helps me know that you find this content interesting. Please subscribe if you haven’t already!

I routinely look at the “about” pages of startups and companies I’ve just learned about. A company of 5-30 people too frequently has a page of titles that are very similar to this:

In fact, I took inspiration from a few that I’d just looked at to make that graphic.

CEOs, VPs, CTOs, Senior VP of Human Resources, Chief Marketing Officer…

The list goes on and on. It’s hard to believe that anything gets done given introductions at meetings must take a half hour.

This type of culture and company isn’t the “gets stuff done” that I look for when researching companies or doing investing. The titles get in the way of a collaborative atmosphere. You can respect someone’s ideas, wisdom, knowledge, and accomplishments without needing a label or a title. If your company is bogged down in these titles, what other parts of the company are getting in the way of getting things done?

In late 1994 early 1995 at Epic, you can see below the titles that we generally had. Epic had been around for 15 years already at that point. Well beyond the startup phase. 😀

As you can see — there weren’t many. I may be forgetting one or two, but I think these capture the essence of what we had pretty well. Epic was very heavily invested in software development and it showed. Software developers made up the majority of the staff. We had no “levels” or titles for developers that had been on the staff for a decade or more. Software Developers were software developers.

Software developers, as generally defined by Epic at the time, focused on all aspects of creating software, from inspiration, design, to project completion and testing. Team leaders did not create designs and there were no architects on staff that were creating boring UML swim-lane diagrams to follow.

Epic was a small enough company that there wasn’t need for titles. We got things done. The things we created became our calling cards, not a title. An interesting side-effect of not having titles was that employees were not scratching and fighting their way for a new coveted title (definitely a story for later during my non-Epic years). Epic’s (unwritten?) policy was to provide opportunities to staff for them to experience growth in skills and responsibilities. Successful staff had more options.

The harder I worked, the more fun I had, with no new title required.

Honestly, it’s pretty easy to spot someone that talks about doing things and has a great title at a company compared to someone who builds software at a company. I understand some level of management, administration, etc., may be necessary part of doing business, but what about everyone else? Is the new hire more interested in their title or the work that they’ll be doing?

To be clear, even without titles, it wasn’t uncommon for more experienced R&D staff to concentrate on some particular aspect of software development and spend less time overall than another developer might on the same task. That’s natural and plays to an individual’s strengths and company needs. One developer might do more code review because the team had hired more staff for example (that’s likely my story for my next Epic post).

My challenge to new software startups: skip the titles and instead make a great product. Be concerned with titles another day (or maybe never?). Concentrate on the success of the people and the collaborative culture.

Thanks for reading my Epic post, but before you go… I have an email newsletter subscription with several support options now available! Please check it out and subscribe! I’ve had a lot of people tell me they enjoy the content but I’ve had so few subscribers it has been tough to be motivated to continue (and it’s a paid service to add to the demotivating factors). If you know of others who might enjoy this content, please tell them!