DEV Community

Cover image for (Meta) Lessons from a failed Data Science Hackathon
1LittleCoder💻
1LittleCoder💻

Posted on

(Meta) Lessons from a failed Data Science Hackathon

About this post:

I recently participated in a Hackathon (24hrs, 5 Team Members, 4 Challenges) and ended up not winning anything. Probably unfair to say I didn't win anything. Perhaps, the learning is what I won out of it (The experience and thrill aside). Why waste such a beautiful failure lesson decay within my brain when I can share it with y'all!

1 Problem-driven Solution vs Tool-driven Solution

The moment I saw an R Hackathon which would involve some Data Communication aspect, My mind was fixated with an RShiny Solution. I'm fairly decent with Shiny so that ego boosted this idea further. But because I wanted to make a Shiny App as an End solution, I had to wrap the solution to the Hackathon challenges fit within a Shiny App. For example, I internationally went to Interactive Charts to present my insights while that was overkill. Similar to this, many such decisions were around Shiny (the Tool) than actually being driven by the challenges I'm supposed to solve. This ended up being a big problem because the ideation process took a huge hit and also took a lot of time leaving me less time to work on the actual problems (even after listing out those ideas).

2 Team Collaboration

We used Slack for Communication and a shared Github Repo for code sharing. But I realized later that wasn't enough. We had members from 3 different Time Zones and we should've picked up a better Collaboration tool. Perhaps, Something like Trello where we can have cards and status so that we all could have collaborated better than how we did. Team Collaboration is also essential because everyone has their strength and sometimes thinking it out-loud and putting it out there(through a collaboration tool with cards-style) can be more effective than just us verbally exchanging those words on Slack.

3 Depth vs Breadth

A hackathon involving Data Communication can be approached in a lot of different ways. You can either try to answer all the potential questions or You can do a few very good. It's a trade-off and it's always good to clarify/discuss with the team which one we're going after. I was thinking too much to offer a few perfect things but that didn't work out.

4 Better Time Management - Time for Insights

Coding is one thing, Plotting is another thing. Documenting / Highlighting Insights is totally another thing. I didn't account much time for the Insights and hence the solution looked like a bunch of interactive charts grouped together.

5 Presentation

For a deadline 11:00 PM, I was making a presentation video ~ 5 mins back. As you can imagine, it was a total disaster. Irrespective of how many good things I did, I didn't deliver it good. End Result: No Result! So, it's always good to put an end to the coding craze and start working on the presentation. For those who like to code, Coding is like Biryani but hey sometimes you need stop eating those and start with the dessert - presentation!

I don't know if anyone can relate to this but hope it's helpful to someone out there:)

Img Credit - https://clayburn.abbyschools.ca/blog/first-attempt-learning

Top comments (0)