My First Coding Competition: Lessons Learned
Introduction
I never thought I’d participate in a competitive coding event, but here we are. When I reached out to a professor in my grad program for career advice this spring, he dropped a hint that he was putting together a team from my school to participate in Go Code Colorado. I wasn’t sure if it was something I wanted to commit to, but I was looking for an extra project to practice my data science skills outside of class, so I signed up.
The event itself was pretty interesting. Each year, it draws everyone from students to startups to use public data to solve an existing business problem and win a $25,000 prize. Each team can choose to build an application or perform an analysis, and there are separate categories for each track. One of the requirements is that every submission use at least one dataset from the Colorado Information Marketplace, a repository for public data in Colorado. One of my favorite features of the competition, besides its use of public data, is that each team has multiple opportunities to connect with “mentors” — volunteers with extensive experience in business, startups, or government, who can help guide participants. The event was also sponsored by a number of prominent software companies that gave teams access to their tools, such as ArcGIS and Tableau, for free.
For our submission, we did a visual analysis of the Denver area housing market using Tableau. If you’re interested, you can read some more of my thoughts on Tableau here. The goal of our project was to enable prospective home buyers in the competitive Denver market to make informed decisions by quickly and easily supplying them with additional data not found on traditional listing services like Zillow. We originally wanted to create a geospatial app using ArcGIS so this information could be retrieved in a fast, intuitive manner, but we later had to scale back for reasons I’ll explain below.
I’m glad I participated in the event, but we had a fair share of difficulties. There were a lot of setbacks, many of which were self-inflicted and could have been prevented with a little bit of foresight. That said, here are the lessons I learned from my participation in Go Code Colorado.
1. Establish Leadership & Support Roles
There’s a reason why many people tend to dread group work. Its difficult to keep any number of people motivated, and one person ends up doing most of the work because there’s no structure. Our situation was no different. In our case, we were a handful of students in different time zones, almost all working full-time jobs, with no leadership. Because there was not a chosen leader, no one wanted to fully take the reins, but everyone had their own idea of how the project should go.
For most of the duration of the project we met virtually once a week to brainstorm what direction we wanted to go. Almost every week, rather than building on the ideas of the previous week, someone would point out the flaws in our current plan and propose a new one instead. Instead of sticking to the original plan, we spent weeks trying to decide on one idea and switched domains multiple times. The lack of guidance significantly limited what we were able to build.
A lot of these issues could have been solved by selecting one person to spearhead the project and setting clearly defined roles for the rest of the group. The one member who had been the most active eventually dropped out and requested we not submit his work because he got so fed up with the disorganization. We were able to pull through and get something submitted in the end, but the lack of leadership was a serious stumbling block for our team.
2. Time Management Matters
Our group was all over the place — literally. We had members coordinating across 3 time zones, balancing class, work, and the other requirements of our daily lives. Finding a regular time to meet virtually was a challenge, and when we did find good meeting times, we were often still missing members.
Managing our commitments to school, work, and this event was a challenge for all of us. When we did finally settle on an idea for our submission, we still struggled to make much progress each week. There were times when I realistically had 1–2 hours a week to spend on this, and I think many of my teammates were in similar situations. This was not a recipe for success.
The multiple demands on our time compounded with our lack of leadership made it difficult for us to make real progress as a group. We would have been much better off if we each disclosed how much time we had available to dedicate to this event, assigned tasks, and followed up with each person every week. We needed a mechanism that enforced accountability and allowed each member to make the most of the time they had for our project.
3. Set Realistic Expectations
We were ambitious on our project. The idea we selected was to build an application using ArcGIS that would allow users to enter an address in the Denver area and see enhanced neighborhood data, such as access to public trails, nearby amenities, demographic characteristics, crime statistics, etc. The thought process behind it was that in competitive real estate markets where realtors are constantly pushing you to view houses, it would enable consumers to quickly determine if a property is in an area they would even want to live. We thought that this would add value to those who were not born and raised in the area, and was inspired by several team members who had wished they had a tool like this when they were dealing with aggressive real estate agents.
Our actual submission fell far short of this. We instead submitted a Tableau Story that only covered a portion of the data points we wanted to cover. By the time we had finalized our plan, we had difficulty getting special access to ArcGIS from the event administrators. Even if we had, though, none of us had any significant experience in ArcGIS. We would have been trying to build the entire app with no experience in about two weeks — on top of school and 40 hour work weeks.
Supposing we had been able to get access to ArcGIS and build the app, we still didn’t have the data we needed. Don’t get me wrong, Colorado’s Data Marketplace is an incredible tool. I love that they provide so much public data that anyone can utilize, and I wish every state had a similar product. The issues that we ran into, though, is that the data is collected by numerous different organizations with no standardization. Some datasets are organized by zip code, others by neighborhood, and some are missing that information. We were able to join the datasets for use in Tableau, but we weren’t able to present a list of neighborhoods and their relevant features in the way we had hoped. With more time, we likely could have dug into the data more and restructured it in a meaningful way, but we were already running up against our deadlines.
The perpetual message we receive from society is to aim high and reach for greatness. There’s times when that advice is inspirational and appropriate, but this wasn’t one of those times. We were excited to participate and wanted to create something meaningful, but we were in way over our heads. The end result was a poorly done, dumbed-down version of our initial goal. It would have been better for all of us if we had been honest with ourselves about what we could achieve given our resources and constraints. The final product would have been much smaller than what we had hoped for, but it would have been thorough, clean, and well-done.
Conclusion
I’m glad I participated in Go Code Colorado, but it was a frustrating experience. These frustrations originated from the three above points: a lack of leadership, poor time management across the group, and unrealistic expectations. By the end of the event, most of the team had quit, and those of us who stayed were frustrated and burned out. And in case you hadn’t guessed, our submission did not do particularly well. If you’re interested in looking at it, you can view it here.
However, the experience was a good reminder that there is a lot more that goes into a project than the technical skillset the members bring to the table. To effectively work together, people require structure, guidance, and good communication. Had we focused on getting these right from the start, I believe that we could have submitted a far more in depth, robust submission with meaningful impact and usability. For any endeavor, getting the organization and structure right is the first step on the road to success.
