Hack Your Way To Glory
I attended my first hackathon during my sophomore year of university and I’ve been hooked ever since. Eight hackathons and two victories later, I feel hackathons have helped shape me both professionally and personally. Reminiscing on those experiences while visiting my alma mater, Nanyang Technology University’s hackathon iNTUition 5.0 as a representative of Panalyt, which was sponsoring the event, after four years of organizing and participating, I thought I’d share some of the lessons that I’ve learned over those sleepless caffeine-filled nights programming to quickly prototype a new idea.
Hackathons are intense sprints, typically under 72 hours, where people work together to ideate, design and build a solution to a problem. While hackathons have predominantly been the domain of software engineering due to the easy accessibility of tools and data, I’ve realized that they are rather an avenue for people from different fields( programmers, designers, subject matter experts, heck even the guy who just eats pizza and presents at the end) to work together to turn an idea into a product. Not that different from an actual product team, right?
Hackathons are the best place to get familiarized with new and emerging technologies, where you get access to the latest APIs and technical support, along with giving back to the community by helping those in need of help. They allow you to test your technical skills by building real-life products, learn a new language/ framework and see how different people approach the same problem from a different perspective. Here’s my experience from a hackathon hosted by Facebook to illustrate the same -
Facebook had just launched their Live Video API, which gave us the idea of building a product to build live group video sharing on Facebook. It allowed users to start a live video and then add other users to the live video where the feed would switch to that user’s feed, ala news channels switching reporters. We settled on the idea after a period of grueling brainstorming, discussing the feasibility in terms of both technical difficulty (after consultation with Facebook employees) and our own estimation on whether we could deliver the product within 24 hours, and scoping out the solution accordingly; much like how a tech team plans out their sprints.
Hackathons revolve around a core sense of community. You get to meet, and in some cases even team up with, like-minded people and mingle within the tech community to form new connections, new friendships and in some cases, even new companies! In addition, most hackathon projects are usually sourced where developers publish their projects online so that other developers might either use it or change it to their specific use case.
Hackathons require you to become comfortable working with a team of people to integrate the different parts of the product, using publicly available source-code and also developing the humility to ask for help from more experienced people when stuck, rather than stubbornly going around in circles to come up with your own solution and wasting valuable time.
We assigned each member of our team different responsibilities based on their previous experience and allocated the android interface, Facebook integration, video streaming and design amongst us once we’d scoped out and architected our product. We quickly built the android login interface and moved to building the live video part of it which involved getting a real time video link and connect the phone to start live streaming , the complexity of which required us to reach out to more experienced people for support. We also helped another relatively inexperienced team facing problems with the Facebook login to quickly integrate the same.
However, hackathons can also lead to programmers developing some bad coding habits due to the time constraints, such as not splitting the code, not following a flow or hard-coding data, as a result of which hackathons projects are usually not maintainable. This brings some problems if these practices are adopted in the long term. While one may argue that the “hacky” solution is intelligent and a sign of quick thinking, developers must understand where they’ve made a compromise and not repeat those mistakes when you enter the workforce.
Our Android app had to connect to the server we made ,receive a video link and then connect the camera feed to the link. It also had a standard login page and another page for inviting friends. Though I managed to build the login and invite pages as per best standards, I had to hard code the logic of the main page of the feed directly into the User Interface due to unforeseen difficulties and thereby losing a bit of integrity to the project in terms of code quality.
In hindsight, I wish I’d worked on maintaining or even improving upon my hackathon projects. I’ve seen teams come up with several great ideas with strong real-life use cases and never follow up on the project once it’s done. I’ve come to realize that while cleaning up the codebase, documentation and making minor bug fixes is always boring, doing so allows not only you but even other people to understand and build on your application in the future.
My spirits were dampened after our app froze during the hackathon presentation despite working during testing earlier. Due to this dejection coupled with mental fatigue , I didn’t take the initiative to make any further progress on the application. I haven’t even updated the readme file since. Sounds familiar?
While hackathons help kickstart an idea and progress it in a short period of time, participants should always keep in mind how scalable, readable and maintainable their solution is from ideation to execution. Your project may potentially be very valuable if you build out your solution properly and find the right use case or product-market fit in more technical lingo.
Hackathons train a person to work long hours under intense pressure alongside other people at the cost of projects built with bad code due to time constraints. Maintaining these projects increases code quality, allowing a user to rapidly prototype using good code, and to improve and scale the project over a longer period of time rather than just a very short sprint. This helps produce short-term as well as long-term results which is what many startups are looking for currently.
At Panalyt, we celebrate quick solutions to technically hard problems that are innovative yet scalable. We have even incorporated hackathons into our work schedule by way of frequent offsites where the whole team comes together to brainstorm and quickly implement solutions to pressing problems. Sponsoring iNTUition allowed us to give back to the community which our developers matured in and going through the products pitched by 50+ excellent teams surely got our creative juices flowing!
I’ve had to learn these lessons the hard way while making the switch from being a serial hackathon participant to a founding member and lead developer at Panalyt and I hope this article helps you realize the same much earlier than I did.
Note: This article was originally written by Pratyum Jagannath, Lead Developer at Panalyt