Learnings from a Hackathon Noob

On Sept. 26-27, Centric participated in the inaugural Cleveland Medical Hackathon at the Global Center for Health Innovation. The goal was to build an app in 24 hours that would improve care, reduce costs and enhance overall patient experience. The team included experienced hackers and first-timers, and not all developers. So what did this disparate group think of the event? What were the lessons learned? In this series of articles, hear their unique perspective on this enlightening event.

The Cleveland Medical Hackathon was my first hackathon, and I found it an enlightening and humbling experience.

Below are the lessons I took away from the event.

Embrace the Spirit of the Hackathon

Gravitate towards the idea that most interests you. You can’t substitute passion, as it drives the desire to commit the next 24 hours to the project.

Don’t Be Shy

The subject matter experts are excited about sharing the issues facing their industry. Be outgoing, and use this as an opportunity to educate yourself about a problem. For example, I learned about the penalties associated with hospital readmissions as it pertains to Medicare reimbursement. This is an issue I likely wouldn’t have been exposed to outside of a client project.

Further, solutions to address this particular problem could be of great value to companies operating in that space.

Do your Due Diligence

Spend a few minutes on Google doing quick-and-dirty business research: Has this idea been done or tried before? If so, why did it fail – or succeed? Is there a way to improve upon it, or make it better? Based on what you find, don’t be afraid to change course and go in a different direction.

Set Yourself Up for Success

Trying to learn a new technology or tool during the event can be challenging. Be flexible to the role within your team, but also be realistic about your strengths / weaknesses.

I tried to learn a new BI & Analytics tool called Tableau to display our sample data, but I stumbled through and couldn’t complete basic tasks which resulted in increased frustration. I reverted back to using a technology with which I was more familiar and found myself much happier – and more efficient.

Learn to Settle

Solutions aren’t going to be perfect; there won’t be enough time. The idea is to develop a rough draft of a solution – failure is an acceptable outcome. You may find that your solution or idea isn’t technically or economically feasible, but the value is in the exploration.

Colin Skopinski is an Architect for Centric Cleveland.  He primarily works with the Microsoft technology stack.