Last week, I pitched my ideas for the Search and Discovery HackDay at my company, and luckily both of my ideas got picked. I decided to take one and compete for this event. I recruited two of my colleagues to join me for this hack.
HackDay is intense. It requires good ideas, great skills and physical endurance, and of course leadership and team collaboration. At the same time, it is so fun and rewarding. It is like building your own business and implementing your own ideas in a quick way with low cost. That’s why I love this concept of HackDay. This was the second time I was competing for a 24-hour hackathon, and the first time I led a team for hacking my idea.
Here are the good and the bad (need to improve).
1. Planning early
I got the estimating skills from sprint meetings.
- “Working backwards” (Write user stories)
- Split the project into small actionable tasks;
- Assign ownership;
- Finish the learning/ramp-up tasks before the HackDay;
- Have a check-in schedule;
- Settle down the mock-up.
2. Checking in on time
Long span projects are easy to slip by due dates because of few check-in times. Check-in times make sure team members on the same page, and focus on reducing dependencies. Even we cannot finish the action items on time, it can be a good chance to communicate and gives us sense of urgency to finish the tasks promptly.
3. Teammates’ commitment
I was lucky that two of my team members made commitment to this challenge. Because it was out of work responsibility, I was really happy they stayed late with me to finish the work.
4. Refocusing quickly
My original idea was about an mobile app related to camera. Developing an Android app in 24 hours does not seem realistic. Luckily, I found an alternative solution using HTML5.
5. Great demo
The demo we had was really really good in my opinion. It was fun and engaging judges and audience.
6. Recruiting the right number
The maximum number of the team was 6, but I thought 3 was enough to complete this project. Bringing too many people on board might make the team hard to operate.
I wish I could trust my teammates more. When we were very tired, and realized we failed to finish items according to the schedule, I was nervous, and prepared to finish my team member’s task if he could not finish. However, it turned out he was slow because he was trying to find an automatic way to get the results. Of course, he provided a good result, but I wish I could trust him more and I could focus on my action items.
2. Making it work first
I was so sensitive to the way I wrote code, that sometimes it took me time to fix namespacing, styles, variables, etc. What it matters at the end is a working demo with a good user experience, which is only judges and audience can see. Focus on those first, and let go the minor things. When you get a working demo, now it is your time to refine everything else.