We conducted our first internal Hackathon of 2015 on the 8th and 9th of January at our Chennai office. The hackathon continues our ongoing tradition of Indix Freestyles. Here is a summary of the ideas, solutions and learnings from this event.
Why an (internal) hackathon?
We started with Indix Freestlyles last year where everyone could work on their own ideas one whole day, every other week. The goal is to foster an environment where we take time off our normal work week, and the pressures and deadlines that go along with that, to work on ideas that the individuals find challenging. We wanted to encourage everyone to work on ideas that were not part of our product roadmap or have not been planned for yet. Moreover, we also wanted to provide an opportunity where folks can work on parts of our system they don’t normally work on.
The two day Hackathon was a different take on this freestyle experiment. We wanted to see how a two day event (maybe scheduled once a quarter) fared against the one day freestyles that were held every other week.
For our internal Hackathon, we decided that we would have it as a two day event starting on Thursday morning, with the demos scheduled for Friday evening. Following on our freestyle approach we decided not to go with a theme, and leave it open so that people can work on any idea they want.
Before the Hackathon
One of the great things about the world-class team we have at Indix is that everyone has a few ideas that they are discussing and thinking about. We started with an idea wall for the Hackathon, as a physical manifestation of these ideas. The intent was to build a pool of ideas so that people could either choose the idea they want to work on or put one of their own. This helped in easier team formation before the Hackathon. It also created the necessary buzz and excitement around the event. Ideas were encouraged, and came in, from engineers and non-engineers alike.
During the Hackathon
The Hackathon kicked off with the pitching of ideas. Ideas were advertised, marketed, discussed, and teams were formed based on interests. And, thus the hacking began! People diligently worked on their ideas, many working hard all-night long. Supporting them was an ample supply of pizzas, Mountain Dew and Idlis.
Demos started around 4.30pm the following day. Everyone presented their projects and solutions to the entire office. The ideas ranged from a Twitter bot that used our API to tweet about product offers, to Machine Learning models for page classification. The excitement during the demo was palpable. Everyone was probably thinking how each of the solutions presented could fit in our workflow, and provide better experiences to us and our customers alike.
Let me present few of the ideas that were worked on during this Hackathon.
The previously mentioned Twitter bot will help people get offers on products they are interested in. Watch this space for news on when you can start following this bot!
One more bot came to life during the Hackathon. It was christened the JIRA minion, a bot for our chat app Slack. The minion work was to streamline our JIRA workflow (creating issues, assigning them, looking up tasks for the day etc.) Also, it is fun to chat with a bot that has an attitude.
Another project was about ensuring that we do not inadvertently leak some of our sensitive data (like AWS keys) to the outside world. The solution involved Git hooks to prevent leaking such information based on predefined patterns and also Github webhooks to alert us when repositories are made public with such information. As we open source more and more of our internal tools, this tool will act as a good safety net. And yes, we hope to open source this tool as well.
We wanted to easily receive whole Git repositories from candidates for our coding assignment. One of the solutions we built during the Hackathon is a service to create and share private repositories via links rather than messing with credentials and keys. This should help us move towards receiving Git repositories from candidates rather than boring zip files.
A Chrome plugin was created as a tool to make power users of our Indix web app more productive. One of the productivity boosting actions that this plugin does is providing visualizations on reports that are emailed out to our users.
The most important learning from the Hackathon is that people are interested in having one. The loudest feedback has been that we should have one every quarter, and we hope to make that a reality. The amount of great ideas and solutions that came out during the Hackathon also more than justify our commitment to take two days off work. All of the ideas will be put to use in one part of our system or another, and will definitely help us serve our customers better.
We also felt that having a two day event provided the right time to conceptualize and come up with good prototypes or even the final solutions for our ideas. With this in mind, we will move away from the one day freestyles that we were having previously, and start having these two day internal Hackathons once a quarter.
There was also an interesting discussion on music while working. During the Hackathon, we had music blasting through the speakers, and everyone was pumped up by it. The obvious question that arose was why we have music during an Hackathon and not during a normal work day. Stay tuned for a future post on our experiments with office-wide music while working.
Challenges we need to solve
One of the biggest challenges is in getting good participation from non-engineers. While there was involvement, we need to figure out a way to have them involved throughout the event. Moreover, while the Hackathon was conducted at our Chennai office, we also need to have our US offices involved so that we can have a true company-wide Hackathon.
We also need to ensure that all the wonderful projects that were worked on are added to our backlog and get routed towards polishing and productionizing.