I spent last weekend mentoring participants in PennApps, a hackathon organized by undergraduate students at UPenn. I enjoyed the experience of mentoring, and had an especially great time pretending to know a lot about hardware.
While working with various teams, I noticed a pattern: although I was not an expert on many of the technologies the students were working with, I was able to help them accelerate their hacks just by focusing on some fundamental engineering skills. Two of my teams won various prizes at PennApps, and I was beyond satisfied.
If you are participating in an upcoming hackathon, do yourself a favor and learn these skills; your team will love you and you will have more time for the fun parts.
Learn to use Git
If you are a college student, you probably don’t have much practice working in teams on coding projects — collaboration was a first for many of the students I worked with at the hackathon. Recognizing the need for version control and having a good understanding of the basics is a crucial for productive collaboration.
As a participant, you must learn how to commit code, merge branches, and revert changes. This will allow you to divide and conquer, experiment with new ideas, and try out various implementations while maintaining a safe checkpoint that you know how to revert to when things go wrong. I witnessed multiple teams losing hours of work because they could not remember what they did before they broke their project with some experimental changes.
If you find yourself commenting out huge chunks of code and labeling them “Attempt 1”, or “Working!”, stop and learn Git.
Stop and debug
Hackathons are frustrating, because your code doesn’t work most of the time. Yet this is precisely the point – a hackathon is an intense period of learning during which you experiment with new application programming interfaces (APIs), software-development kits (SDKs), frameworks, and even languages. Expect problems and learn to fix them.
Instead of throwing your hands in the air and yelling “it doesn’t work!” – learn to ask, “what is the error?” Rapidly narrow down the space of possible causes, using binary search if you can. Insert print statements, set breakpoints (if possible), and find error messages. Figure out how to reproduce the problem quickly and reliably. Unless you have noisy input or random variables, your code should behave deterministically. It is “magic” only if you don’t understand what you wrote.
After the initial investigation, form a hypothesis about the cause and test it. Comment out chunks of code selectively to isolate the cause.
As a mentor, I usually think aloud as I work on debugging the problem to show other developers how to determine the cause of a problem and create a fix.
Use Google (intelligently)
You get stuck. A lot. Google is your friend, but sometimes it’s hard, especially if you don’t know what you are looking for.
Start by figuring out specifically what you need to learn. What function do you need? What could it be called? If you were the engineer who built on the library/API/SDK, how would you implement it? Where would you put it?
Start searching on Google. Speed read though the first few results to determine their relevance. Use related content to guess and discover keywords until you close in on what you need.
Finally, form hypotheses from what you’ve learned, and test these hypotheses. If necessary, validate your learning using tiny examples before trying to work it into your current project.