My Experience at MHacks

MHacks is a hackathon at the University of Michigan. My company was a sponsor of the event this year, along with larger, more well known companies like Intel, Target and Disney.

I got to participate as a mentor, which basically means that project teams that are looking for technical guidance seek out mentors for assistance.

My specialty is Healthcare IT. There were two project teams that I had the pleasure of working with.

The first was a simple series of web baesd forms that asked some lifestyle questions and asked for the person's height and weight to calculate and display their body mass index (BMI). The actual calculation of BMI would be done in javascript on the web page. It has been over a decade since I did any web based programming, so I sent this team off to find some web based developers to get the syntax right.

The second team was more ambitious. They wanted to have web forms/apps that allowed a patient to update their demographic information and to schedule a visit with a doctor. I outlined the basic standards that support these data exchanges and then showed them the FHIR resources that were available to support this exchange. There are a couple of test servers out there that you can exchange with and they were going to use those as the back end for their app. I told them to emphasize that their solution was "standards based."

All in all, it was a very cool experience to see so many young people who are enthusiastic about technology.

It's all about how you recover

There is a lyric from Marillion that goes like this:

Failure isn't about falling down,
Failure is staying down.

I am in a leadership role in my present job. I work with a team of developers in the role of EDI Architect. We primarily move data between our internal systems and external trading partners.

One member of the team is a Senior Developer with lots of mainframe experience who is very new to the technology that we are using as our interface engine. This engine has a visually based development environment that can be challenging for a traditional "looking at code" developer to get comfortable with.

This week we promoted the first of his projects to production. The next day we realized that we had configured things wrong. He got very flustered. I told him to take a few deep breaths and then sit down with me while we figured it out. I told him that we needed to make sure that the change that we made was correct and that that was more important than making the change quickly.

We sat down and analyzed the problem and came up with a solution that we both agreed with. When we made this change, I brought each component up one at a time to make sure that they functioned as expected. We looked at the data flows and verified that they functioned correctly.

When we got done, I told him "We all make mistakes. It's all about how you recover."

I have now added a couple more things to the list of things that I look at when promoting to production. Hopefully, we both learned something.