A few weeks ago, we decided to do a Post-Christmas Hackathon between our tech mastermind Thilo and myself. Not that we are not spending enough time looking at computer screens; this was going to be different due to a few rules that should help us avoid distractions. Because even though focus is an important principle of ours, reality often gets in our way.
We knew that doing something like this has a few benefits that are harder to get by during a regular day. Hoping to inspire you to do something similar, we are sharing a few observations. Because this is going to be long, we will be breaking it up into two pieces. Here is what you can expect:
Here are the basic rules we set for ourselves in order to be productive.
On top of that, we knew about the soft aspects of hackathons, such as coping with less sleep, chaos piling up on our desk and eating more snacks than usual. While the latter is an ideal of ours, reality has shown us time and time again.
When setting up the plan and above rules, we did not have a specific product in mind. There were a few ideas in the pipeline that we would get to "eventually" but no matter which one we picked, each one was going to be experimental. So we tried this:
After our Twitter idea had failed miserably, we decided to go for a separate product: The dataset builder.
The idea for the dataset builder was born while working on colabel's first functionality, where we needed to collect a variety of labeled images in order to test the performance of our software. And although there are some places where such datasets can be obtained (e.g. Datasetlist), we quickly hit a limit and needed to build our own. And that can be quite tedious at times!
The dataset builder makes it easier to get a labeled dataset for computer vision problems. It is not an innovation in what it does, but it makes the process of preparing a labeled dataset much easier than doing so by hand. In addition, image files do not need to be stored somewhere but can be pulled from the original source when needed. And since image datasets can become quite large in size, this allows for lighter setups for experiments.
The dataset builder is one of many projects in our codebase that are missing the final ten percent but are too good to dispose. Or as we like to call them: the living dead. A former colleague of ours had built the application to a state where it was technically ready and visually appealing. Before going out into the public, our main concern was to obtain a self-explanatory user experience.
Note: If you are not a programmer, you might want to move on to the next section
Until we took over, only one person had been working on the application. We found ourselves in a well-structured React app, featuring Redux for state management and Material UI for the looks. The backend was written in Python, which calls the Bing API, stores contact details and delivers the requested data via email.
That alone does not sound too exotic. In fact, it is the standard setup for many applications nowadays. However, neither of us had worked with React and Redux. You might say that we are crazy for not doing so but so far, there really was no need for stable infrastructure on the frontend. On top of that, we could not ask the app's creator why decisions were made in a certain way. After all, there are usually more ways to accomplish the same goal and everyone develops certain preferences over time (and code is obviously not documented). Summing up, we would be learning something new.
Besides providing value to a large community of data scientists, we wanted to get some experience with product launches and marketing as a whole. Luckily, most of our current customers came through word of mouth. But at some point we want to go broader into the market, and therefore going through the drill with the dataset builder sounded like a smart thing to do.
Hence, our rough plan had three simple steps:
Sounds simple indeed. However, we had underestimated a few aspects in our plan. More on that in the second part. Stay tuned!