My experience at Code with a Cause STL

2 minute read

People at Code with a Cause

Just last weekend, I attended a hackathon downtown called Code with a Cause. Here, I’ll go over how the event went and what was learned.

What was it?

Code with a Cause was a hackathon to help local nonprofits. Nonprofits would send project proposals which would be tackled by teams of participants. The goal at the end of the 3-day event was to have a solution available that alleviated the problems of the nonprofits. The event was noncompetitive and collaborative. If a team had trouble in one area/technology, members of other teams were encouraged to help out. On the last day, teams presented the projects they completed over the weekend.

What did I build

The team I was on integrated a real-time messaging solution for one of the non-profits that were part of the event. This was integrated into their wordpress site.This would help their clients besides taking calls on the phone. The messaging solution we ended up utilizing was called LiveChat

Why did I go?

I went because I’ve always wanted to build things that could carry an impact and help benefit society as a whole. By building software for non-profits, they are able to focus on their mission rather than lose precious time in logistics and paperwork. This is just one way I’ve thought I could help provide an impact. I also wanted to gain more skills in presentation, leadership, and communication. I wanted to see what it took to build something that is to be used by clients or an organization.

How was it useful?

It was way more useful than I initially thought. The core lesson I learned was that one should not try building everything from scratch. Oftentimes, there may be preexisting products on the market that can be tweaked to be of value to a organization/company. Initially, when the event started, I was very keen on coding the project. However when we conducted more research. It became apparent that there were several solutions already out there to accomplish the task. I learned that I should not get too attached to whatever I build as well for it may or may not be of actual use to the outside world. I learned how to better set aside my individual way of doing things, and think in terms of what was best for an organization/company not what would look the “coolest” or “modern”. It was also useful in regards to giving me more presentation experience as well.

Michael Navazhylau (a.k.a Mechasparrow) is an engineer that loves building stuff, philosophy, and other creative endeavors. You can check out my website at Mechasparrow.

Twitter Instagram YouTube Website GitHub