What I Learned from Imagine Cup

Over the last month and a half, a group of friends and I have been working on creating an app for the Imagine Cup. For those of you that don’t know, Imagine Cup is Microsoft’s annual innovation challenge that has students team up to develop solutions that tackle pressing issues. Our app focused on aiding the caregivers of those afflicted with dementia, a population of 50 million people worldwide. Built over the course of a hackathon weekend, the app leveraged IoT and AI to provide real-time context and geolocation data of wandering dementia patients to their caregivers and loved ones via companion app. In short, it aimed to provide peace of mind to the caregivers while safeguarding the autonomy of those experiencing increased cognitive decline.

From late January to early March, we hustled to get as much of our software done as possible. We reached out to social workers and hospitals to inform our design processes, and each familiarized ourselves with entirely new technologies to bring our product to fruition. We put school by the wayside and grinded out as much of the project as we could, pulling multiple all-nighters as our academic obligations piled up.

In the end, as good as our solution was in theory, in practice, we weren’t fully able to implement it. Having strayed so far from the milestone we had initially set, we decided against submitting to the Imagine Cup . At first we were all heartbroken: we had put entire days of our lives into that project, and some of us had taken hits academically. In all honesty, part of me is still a bit dismayed at the outcome. That being said, I learned a lot about myself and working in teams, insights I hope to apply to future such endeavours. Here are some of the main things I learned:

If you can’t fix a problem in the first 2 hours, reconsider your approach.

What actually happened: There were multiple bugs we faced during the development process that absolutely stumped us. We had decided on using Ionic as our front-end framework, despite the fact that we were mostly unfamiliar with it. Compounding this problem was the fact that Ionic is not a very commonly used framework, meaning StackOverflow couldn’t save us as much as we were accustomed to. This meant gruelling hours spent debugging issues later revealed to have incredibly trivial fixes (think missing colon type of trivial). On one such error, my partner and I spent 7 hours entirely baffled by Chrome Developer Tools’ insistence that the directory we were searching for didn’t exist. Not only did these situations waste inordinate amounts of time, but they also eroded some of the passion we had for the project on the whole.
What should have happened: Instead, we should have passed on the problem to a fresh pair of eyes, for instance our third teammate, who eventually was the one who solved the issue. Had we done this two hours in, we could have had a far more productive day without feeling like we were bashing our heads against a brick wall. Another possible option would have been taking breaks to let ourselves reframe the problem on a new attempt.

Punctuality truly is a virtue.

What actually happened: I can’t even begin to express how many times meeting at 2 p.m. became starting work at 4. Between everyone’s crazy schedules, finding a time everyone could meet was already difficult, but making sure everyone arrived on time proved to be even harder. Not only did it give us less time to get things done, but it was irritating to mentally prepare for a meeting and then be stuck waiting for hours on end. ** Admittedly, there were times where I was the part of the problem as well.
What should have happened: We should have set expectations right from the beginning. Two o’clock means two o’clock: no earlier, no later. Given that we hope to continue working together at a startup accelerator this summer, it’s only fair that we learn to respect each other’s time, otherwise this is going to be one hell of a summer.

There is such a thing as too much pivoting.

What actually happened: This is a me-specific problem that I only just realized while writing this post. There were times while working on this project that I thought it wasn’t good enough, and that we were wasting our time in the direction we were heading. At these points, I frantically racked my brain for potential ideas to pivot to, which in retrospect wasted a lot of time that could have been spent improving the tech.

What should have happened: While trying to build something you genuinely feel is incredible, it’s only natural you might second or even third-guess yourself. While on one hand it is important to give yourself occasional reality checks, it’s probably not very beneficial to be constantly revising your idea instead of making it a reality. Instead, look at the product you have and critically analyze it, pointing out its strengths and weaknesses. From there, strategically try and morph those weakness into strengths if you can, or mitigate their downsides otherwise. Such an approach will likely be a lot more fruitful than abandoning your idea on the whole.

Overall, I’m extremely thankful for having had the experience of getting a project like this together. I had never worked in a group project for tech outside of class before, and to see everyone’s intrinsic motivation shining through day in and day out was truly motivating. I hope that in the future these insights will guide how I approach building tech, and maybe one day I’ll finish something I’m truly proud of.