Skip to main content

What I learnt from my First Hackathon

I often used to awe at the possibility of someone coding for 2 straight days continuously. I couldn't even sit for a 3 hour test. "But that's only because I was bored". I realised this only when I actually sat for a 2 day hackathon and built an amazing Android Application! In this post, I talk about my 2-day coding journey, and how it changed me from a 'newbie developer' to a 'newbie developer who had an awesome project to his name'!

Identifying the tech stack

Okay, I had teamed up with my friends, registered and now we all sat down to decide what we would make. None of us had any kind of big start-up idea, and even if we did, there was a high chance we couldn't make that because of our limited coding knowledge. Note: We were still in the first year of our college.
So we decided to first analyze our technology stack, that is, what is the platform and programming language that we would use to make our hackathon project. Android Studio was quite trendy in my class at that time. I had learnt the basics of it a month ago, and out of the 4 of us, there was this one guy who was simply awesome in Android App Development. For those unaware, Android Studio is a software application (IDE, actually) that is used to make apps for Android mobile phones. So whatever we did, we knew we had an expert with us to save the day; or at least we thought so!

Ideation

Now that the platform was decided, we thought of ideas; the only constraint: It should be an app, not a website. So we went through many smaller ideas. We didn't want to select any idea that was bigger than us which we would fail to complete by the end of the day. Someone came up with an idea to build a donation site for multiple NGOs, or make a notes sharing app for our college. One of my friends came up with building a coding editor for mobile phones. We loved the idea. No one codes using their mobile phones. Why? It's really inconvenient. Why? There is no easy access to all the special characters such as ; (or : if you're smiling being a Python user). Anyway, mobile phones have a restricted keyboard and no one wants to code by long-pressing characters. The laptop way to code is much much better. But, if we could eliminate all the grievances of coding in Android by making an app, that shit would be legen...wait for it...dary! Yeah, we were so excited that now when I write about this, the idea seems lame in front of the celebration. But here were the main features we thought the app could have:
  1. All the special characters like semi colons, curly brackets, colons, backslash, etc. could be in a drawer that could be accessed just by a simple left or right swipe.
  2. Certain code segments like having for, while, or do-while loops, switch statements could be written just by Voice Recognition. For example, you say, "Add a while loop", and the app adds the following to your code:
         
    while(/*test condition*/) {
          /*body of the loop*/
         }
  3. The user could also add Code Segments/Snippets that they would like to say which they require more frequently.
    We thought of many more features, some of which we rejected due to incapaility to build those, or irrelevance. But the point is, we were passionate about the project.  

D - Day 1

The first day of the hackathon arrives, and we brought our laptops and passions to the coding room. I actually felt really good entering into the room, looking at our table, sitting on the allotted chairs. It was almost like, years ago, I dreamt about going to competitions or meetups where I would do wonderful things, and the day was here. And just when I thought that this is the day, it wouldn't feel that big a deal. It wasn't a bad feeling nor a proud emotion. It just felt good. The time began and we started coding. Luckily for us, we all knew idea what Github was(a code sharing site for programmers, but it's also much more), so code sharing was not that tough. I had quite a few projects on Github, so I was well-versed with the git commands. Everyone in the team was accustomed to basic Github functionality a few days before the competition. For complex git commands, we had me. That sounds weird. Anyway, we fired up the site in all our browsers, and made a common repository (project folder) for the project, and began coding.
I still don't know any better management principles while programming in teams, but we divided the work in whatever ways we could think at that time. Paras, the guy who was the most experienced in programming Android Applications, took the responsibility to code the main functionality of the app. You'd say that's like almost making the entire application? Yeah, that's what he did. The rest of us, started making the UI. We divided really small works that looked like a huge task to us at that time. I remember I took at least 20 minutes to decide the background color. But all the time, I was actually learning. We were making something which we'd never done before, and for most of us, on a platform which was quite new too. I never realised how it was 6 pm, and the day break was declared. Since this was a college-level hackathon, it wasn't so intense to involve night time. We went back to our hostels, really happy with our progress. I had learnt enough for the day, and I wanted a break. We were really tired. So we did what any logical person would do: Immersed ourselves in...Gaming. It was 1 am now, and the body was totally drained. This is what we call being Dead.

D - Day 2

So we reincarnated the next day, and went back to competition for Day 2. The deadline time was 4 pm today. We made a lot of improvements. This time, we also contributed to the functionality of the app. Once we had made the major application, it was time for the secondary stuff like adding app icon, rethinking fonts and background color, etc. But in between the work camesomething that we never knew would be so common in our future project development endeavours...Bugs!! App crashes, weird responses and so many other things started coming up and it looked like we wouldn't finish our project on time. But as I said earlier, we had an experienced coder with us, and so the pressure of unfathomable bugs and adding complex functionality fell back on him. And yes, he completed the project. We were all really happy by the end of it. Although I didn't contribute much to the project, I was happy to see it get completed and was satisfied wih my contribution. I did what I could, and I learnt as much as I could have in those 2 days.

Judgement

Next, the organizers came around looking at our project and judging our idea. They heard us, saw the app, saw the code, gave their scores and left. Now we had to wait for the results. It wasn't long when they announced the shortlisted teams in the auditorium and voila, TheBuggers (our team) got selected! We had to prepare a presentation out of it now, and that was another huge task. Anything looks great as long as you make it look awesome. So it was decided, my friend Abhishek and I volunteered for the presentation, and Deepesh (another friend and teammate) made the presentation. We also recorded a demo video of our app, and started preparing the speech. We had roughly 30 minutes to do all this, and I still remember we did all of this in our college's Student Park! Anyway, when it was our turn, I talked my heart out for this project and how I thought that it could actually make the world a better place (Silicon Valley reference). I felt amazing after the presentation. Here I was, 8 months into my new college, and I had successfully participated in a Hackathon. An event which was purely related to coding made me go up on the stage and re-use my speaking skills. I've always loved going on the stage, but I never thought I'd be there through this. I was amazed at life's possibilities.

Result

About 2 months later, the results were announced. Our team got the award for the 'Most Innovative Hack'. We were extremely delighted. Although we didn't win, or weren't runner ups, we were totally fine with it being aware of the fact that the event hosted student participants from second, third and fourth year too who had wayy more technical knowledge than any of us.

Lessons

This competition happened a year ago. I learnt many things, and got the push to learn many more. After this hackathon, I pursued an intense training in Web Development through many online courses. I learnt Front-End through FreeCodeCamp, learnt JavaScript through books, learnt Back-end in NodeJS, MongoDB through Udemy, and made many more side projects in the last six months, which were not single webpages, by the way!
Conclusion
To summarise, I think I would say this is what I learnt through the experience:
1. Just go for it. The thought of going for a Hackathon might sound really frightening for a new programmer. I know some people who backed out of the competition citing their inexperience as a reason. It's a valid reason, no doubt, but an invalid excuse. If you have even made a single code file, you know how to code. And if you know how to code, just go for it.
2. Team-building. Yes, it's a great platform for you to learn, but there's always an aim. Make sure that you don't forget that you actually have to complete a project, and not just learn. That itself will make you learn. And for that, you need a team that can do that. Find at least one person who has a considerable experience with the tech stack that you're thinking of building the project in. At least someone should have the answers, or at least the way to find them!
3. Tech Stack I don't know a single programmer who excels in all the languages and frameworks equally. You have to find the language and platform which would be suitable for you and your team. Alternatively, you can find a tech stack first and then go about finding appropriate people for the same, but I'd advise you to go with the former, since you'll be much more comfortable with your friends as a team, and that is very important.
This is all I can think as of now as the major points. So this was my experience of my first ever hackathon. I am eagerly waiting for this same one in March this year!
You're welcome to look at our project code, unfortunately we couldn't deploy it to the Play Store.

Here's a look at some of the photos from last year:









https://github.com/deepmanwani18/Say-in-Editor
EDIT 1: As I said earlier, we'd made a demo video of our app, and here's the link for that too: 
   Youtube Link
You can also have a look at the annual hackathon which I participated in:
www.hackonhills.com
This is going to happen around March. So if you're anywhere near northern India, do try it out!

Alright, that's it from my side. This is Utkarsh Singh, signing off!

Comments

Popular posts from this blog

Namaste JavaScript Quick Notes

Note:  Akshay Saini's Namaste JavaScript is probably the best course for JavaScript developers out there. These are my personal notes that I made while watching the course; they serve more of as an online quick reference for my understanding and revision, and I hope it benefits anyone reading it too! Everything in JS happens inside an Execution Context. Before a JS code is run, memory is allocated and variables are set as undefined   , and functions are set as their exact code in the scope within the Execution Context. The global execution context hosts all the global variables and function definitions. An Execution Context has 2 components: Memory, that stores variables and functions; and Code, that reads and executes the code. Call Stack maintains the order of execution contexts. Since JS is single threaded and asynchronous, at one point of time, only one function is executed which is at the top of the call stack. For each function, an execution context is created before executi

An introduction to APIs

API is an acronym for Application Programming Interface. Let's start with first defining some basic terms: Browser: These are browsers. To visit any website on the internet, you need a browser. Server: Hmm, this is tough. In simple words, server is a computer. Yes, just like the laptop, or PC at your home. The only difference is that it does not have a screen. Of course, there are other differences in technical specifications, but at its core, the server is just, simply, a computer. That's it. So why is it called a server? Because it serves . When you go to a website like google.com , your computer connects to the internet and gets you your search result. But your computer's internet connection has to get that result from somewhere, right? If the google search result is giving you some answers, the answers have to come from somewhere. What is that place? The answer to that some place is: a server. When you click on the search button on google, or hit enter after typing, &q

Review: Nestjs - Finally a scalable way to build APIs

I have been thinking about this for a long time. There HAS to be a defined way to build APIs in a scalable way.  If you have used Node, Express, etc in your side projects, you might have felt that after a point in development, debugging truly becomes a pain. Sure, enterprise-level API codes are great. But a lot of times, these configurations are too much, and probably not even needed in other projects. To be honest, I haven't seen a lot of Open-Source API codes either to make a judgement on how experienced developers build their APIs. Anyway, I came across an amazing framework recently, and I think if you are coding a complex API, this should be your way to go. Nest.js Nest.js is a framework for building efficient, reliable and scalable server-side applications.  You essentially break your APIs into controllers, services, and modules, which allow you to modularize the smallest of functionalities in your endpoints or the API as a whole. Why is modularizing important? As I have talk