Keep Hacking On

This past week I went to my first hackathon, to be honest, I was excited to take part in something coding related outside of the classroom. This hackathon was different from other hackathons ( as to what I envision) because every team was trying to attack another teams project. A usual hackathon has a theme and each team is supposed to build a functional project over the course of a day or two. This hackathon was different in that each team had to attack another person project or code so that they would come up on top. So instead of building something with my partner, we had to build a plan of attack and defense. Below I go over how the hackathon progressed and what I learned in my first coding event. Before I go on let me go over the rules first. Each team is given a square to defend, at the end of the game the square that keeps itself the most pristine at the end of the 8-hour competition wins first place. You were given methods to set a tile to a certain color and to check what color the tile was. You can make any color on the board any color you want. It does not matter how many of your pixels were on the board but only your boxes color percentage remained after the match.

Initial Game Board

So you can set and find colors of pixels, it seems easy after reading this article but it was the utmost confusing when I was at the event. The first thing I learned at the hackathon was to ask questions! The mic volume sucked, there were too many not funny jokes, I didn’t care for the fun and games, I came to compete. I was completely confused at the beginning of the event and by staying silent I only burned time by trying to figure out how the rules work when there was numerous staff wanting to help out. After I finally knew how the game worked, it is best to come up with a plan of attack with your partner. I cannot stress this enough, even though I felt the need to code at full throttle, going in blind just to have something on the page does more harm than good. It is best to read through the documentation and see what functionality there is already in the code, so you 1 don’t rewrite code, and 2, in understanding the working parts you have a better plan to win. After you have your plan and know the code it is time to write some. Do not worry about coming up with the most complicated all edges cases satisfied code, it matters more to code and refractor as you continue in the event. I think the biggest lesson I learned was to have fun and to not be consumed by the competition. Work with others and talk it out, this is not some bunker where you are alone to yourself, this is a public event and you are meant to collaborate. As the time went I began to ease up and enjoy what I was doing as opposed to the beginning where I put this self-imposed stress on me. By taking the stress I was able to code better and collaborate more.