Competitive Programming, a beginners POV
Tags: hackathon, competing, beginners
Published: 2018-05-01 14:48:46

---
title: Competitive Programming, a beginners POV
published: true
description: What I've learned from my first programming competition
tags: #hackathon #competing #beginner
---

Beginning developers are often encouraged to engage in external practices, most of which consist going to meetups, attending conferences, and participating in competitions. Although all of the above is fun, educational and extremely memorable, there is a lot unsaid about what some parts feel like. What often isn’t covered is the underlying anxiety of breaking out of your comfort zone, or how hard some experiences may be.

Last weekend I participated in my first competition, a time frame of just under 24 hours to create an Android application aimed towards helping others. I competed with friends and we were a team of five with very different levels of experience. Competing revealed aspects of software development and soft skills that did not seem so blatant, all of which paved the way for different lessons to be learned. Here is a list of such truths that I discovered and what can be learned from them:

1. *Everyone has some specialty and you may not even realize it.* It may seem somewhat like a given, but it’s more of an assumption. You never truly see what your friends or teammates or classmates are capable of until you’re all given a moment to utilize your skills. Even a brief “Yeah I do ___ on the side” is lackluster in comparison to what a person (even yourself) is really capable of doing in a given amount of time.

2. *Sloppy code is better than no code.* For every amazing, well-read, articulated piece of literature, there existed some terrible first draft that is kept hidden; even this post had a terrible first draft, why not do the same with code? Most code written on the first try has aspects that can be improved whether it be syntax or logic. That’s why refactoring is encouraged, in an effort to make code much more readable and efficient. There’s nothing wrong with starting out messy, so long as you take care to revisit and make the proper improvements.

3. *A working project with a minimal UI is better than a UI that does nothing.* It is hard (near frustrating) to not think about how pretty and pleasing you want your project to look, especially if that is what you enjoy the most. By creating the logic and functionality of a product before the UI, you’re able construct the core functions that make the bulk of the application. If, during the function design, you decide “Oh, this piece would help!” and would take minimal time, you’re able to do so without having to redesign the entire UI. However, making the UI first restrains you to what you have initially thought of, barring you from new ideas that you would enjoy implementing or what you think the user may want.

4. *Competing is fun, just don’t forget to break.* Drink some water, stretch, and have a snack (or even a meal if possible.) Seriously.

5. *Communicate.* Both you and your team have different thoughts about what should come first, what should be prioritized, and how to complete objectives. No one is capable of reading minds, so make effort to say “Hey let’s get _____ done before the hour ends” or “I’m going to do _____ this way, what do you think?” You and your team’s input on how the project is going is just as important as the output to be delivered.

6. *Regardless of what you’re working on, be quick to ask for help.* It’s frustrating sometimes to be amongst talented and hardworking individuals, while you’re stumped on a single issue that even a stackOverflow search won’t solve. However, just because you need help doesn’t make you any less talented than your teammates. Guaranteed that they hit a hard obstacle and spent the same, if not, more time to find an answer, however the longer you spend without succession is the longer amount of time that has been wasted. Remember that you and your team are all composed of different and talented minds, so it is highly possible that someone could offer insight on how to overcome a problem

7. *Enjoy yourself.* It’s cliche and it’s overused but it is 100% true. Yes there may be an end goal whether it be a cash prize or a job opportunity, however at the end of the day you gain the developmental experience regardless of you win or not. You learn how to perform tasks that may have seemed unimaginable prior to competing, as well as networking with individuals who you thought you would have never seen in such a setting. Focus on learning the skills to try to finish what you started, and find out what you can learn from other people in the process. This is not limited to your teammates, but the other teams as well, and this is where high competitive spirit needs to be set aside. Breaks are the best time to talk to other competitors, most which are just as frustrated, stressed, and tired as you are. The best laughs and jokes and memories come from these moments amongst you and everyone else at that competition. First place is nice, but it’s nice, if not, better to have fun and not forget to learn a few lessons along the way.

It can be intimidating at first, and it may feel like some kind of club of elites competing for the grand prize. Realistically, it’s just a group of ambitious minds that want to try their skills. I used to think “Competitions are way too cut-throat for someone like me to join” until I actually gave it a shot. Now it’s become a huge desire to continue. Take the chance, be willing to try and learn and do something different, and enjoy yourself!

This post was originally made on [Medium](https://medium.com/@lacanlale/rapid-coding-under-pressure-my-first-competition-66cfe2a8ce3f)! I also run a blog where I post about my projects and interesting tidbits I find through my programming experiences :] Check it out! http://lacanlale.weebly.com/