Lessons from my first hackathon: Fight the Lady Killer Codeathon

fight the lady killer logo

This last weekend, I took part in the Fight The Lady Killer codeathon which went from October 2–4 at Cal State LA. Armed with plenty of sleep and caffeine, I started the codeathon filled with excitement to build an app an three days.

This was my first hackathon, and it was lots of fun; I definitely learned a lot, especially about how to work in a large group to try to make something under pressing deadlines. (Each difficult tasks in and of themselves!) So I wanted to share what I’ve learned from this experience both for my own reference as well as to help others in their hackathon experience.

64percentdie-01

Our team was called I Heart Women and our app was called HerBeat, a social app that would have helped women improve their awareness of their health through fitness and health challenges.

 

herbeat logoiheartwomen grouppic

herbeat login page

herbeat home page  herbeat information page

herbeat challenges pageherbeat log page

I came in at the beginning of the codeathon amped up and ready to code a full-blown app. I was bouncing off walls when I realized I was accepted, half-literally. I had a new Digital Ocean droplet set up—database, users, and all—a new Bitbucket group and private repository for the code, and packages all installed and ready.

I mean, I was excited. I was ready to just get down to the coding just like that.

I was also excited to work with other developers. At work, I’m mostly a one-(wo)man show, and though I’ve worked with other developers on side projects before and gone to my share of tech meetups, I’ve always wanted to work with other geeks to make something and learn something new at the same time. It’s always exciting to talk shop with other developers since there is just so much you can learn from their experience and different perspective.

But of course, Murphy’s Law. Everything that can go wrong, will go wrong. Often, not everything will go as planned, and this time was certainly one of those times. But I think it’s precisely that it didn’t go as planned, though, that I learned so much.

Keeping the focus

Simple. Keep ideas simple.

Really, I feel like our idea was awesome (…alright, I must admit I’m biased), but to actually code it would have been an immense endeavor. I must admit to contributing to the bloating of our initial idea though, since I’ve always had a habit of trying to figure out what else we can do to make it even better…with the eventual result of too much functionality and too much complexity. (I was pretty adamant about adding an information/user blog section too, to allow users to post their own content). Our ideas for the app evolved quickly and were in constant flux and evolution. It was hard to keep up with it at times.

To keep our vision clear, we should have a centralized document (in Google Drive) to keep track of our current project “brief”. This would be where we would write down all decisions regarding the project and its direction, so everyone can be clear about what it is exactly that we are working on.

This time, I have to admit, I was very confused much of the time we were working on the app, since sometimes what I thought we were working on was different from what other teammates thought that we were working on. Sometimes, the ideas changed so fast that team members were left in the dust, since the decisions were not written down or recorded anywhere!

The project specification document would have information such as the project name, a brief mission statement/description of the project, features that we want to include, features that we must include as our minimum viable product, and the priorities of these features.

Assess Strengths and Weaknesses

The first thing to do when you find a group should be to understand what everyone is good at.

I don’t mean simply going around and saying “I’m backend/frontend” or “I know PHP/Java/Python….” That’s great too, but I think it would have been even better to ask what they are best in, and what they’ve actually built and–if possible–to see examples of their work (e.g. Github).

Otherwise, it’s very hard to gauge who is the best fit for what kind of work, and whether or not they will do a good job at it.

Everyone has areas they are strong in and those they are not so strong in. For example, since I am a full-stack developer my strengths include my versatility and more holistic view of the entire web development process. I like to think of things from a system or architectural level, and I am forever trying to find the perfect tool for different situations. But, currently I am only familiar with LAMP and MEAN stack, and my versatility does come at the price of specialized knowledge.

I would not be much help when it comes to working with .NET or making iOS/Android apps (yet…I’m learning Swift now!), and–though I could certainly figure it out–I would not be as fluent and fast as an expert database administrator whose sole focus is database administration. Also, when it comes to public speaking…let’s just say that I still have a long ways to go, but I’m doing my best to work on it.

Similarly, everyone has things they are more familiar with and strong in, and things that they are not. It’s best to quickly find out about these strengths and weaknesses in each member of the team from the very beginning so that we can make the most of everyone’s strengths for a greater collective strength and delegate the best tasks to each person.

Organization

With any group project, organization and clear communication is essential. As such it is important to establish the organizational setup early on. For example, ideally, it would be best to:

  1. Get everyone’s phone number, email addresses, and Github/bitbucket accounts, if any.
  2. Quickly get everyone onto a team communication program such as Slack.
  3. Set up/decide on a centralized Todo list program (e.g. Trello/Wunderlist) and ensure that everyone is able to access it
  4. Sketch out a general list of things to do in order to reach the finish line
  5. Start on the brainstorming
    1. Everyone write down five ideas they have (set a timer)
    2. Post up ideas on board, then go through them one by one, asking the one who wrote them to explain further, adding more ideas/editing as they go along
    3. Using round stickers, everyone goes around and votes on their top three favorites
    4. The highest scored are further discussed and synthesized until a final solution is found
  6. Site structure/content
    1. Decide on what the site architecture will be
      1. What pages/content?
      2. Wireframes
    2. What will be the frontend? Who will do it?
    3. What will be the backend, if any? Who will do it?
    4. What kind of data structures/API do we have/need?
  7. Split up into groups to work on individual components
    1. Design works on providing image/design assets, desigining the presentation, and making the final mockups
    2. Frontend works on setting up the frontend, working together with design
    3. Backend works on setting up the backend/API based on the data structures/API that was worked out
    4. Presentation works on organizing and practicing the presentation, with the aid of design

Agile/Scrum Development

Working in defined sprints would have helped keep everyone on track immensely. Before we start splitting up to work on different aspects of the project, we can first define what each sprint’s goal is and the time period for each sprint. Then, we could split up into different groups to work on different parts of the project, checking with each other every few hours or so to see what we’re all doing. When the sprint is concluded, we could meet together to see how we’re all doing and touch bases before moving on to the next sprint. In this way, efforts are more focused and it is immediately apparent what the immediate goal we’re working toward is. Since it’s a hackathon though, it would be Scrum on steroids.

To keep track of the tasks that still need to be done, using a Google Drive document or spreadsheet as a basic whiteboard to write down what everyone is currently working on might work, but I think that using a Kanban board to keep track of our tasks like Trello or Kanbanflow would have been even better.

With a Kanban board, the general idea is to have three main segments of the board: (1) Pending, (2) In progress, (3) Completed. When a task is to be worked on, the task moves from pending to in progress, and you can see who is currently working on that task as well. In this fashion, it is easy to see who is working on what, and whether or not WIP is starting to pile up.

This would have been helpful in the hackathon since a clear depiction of what needs to be done and what is currently being done helps keep everyone on the same page, so there won’t be teammates that become overloaded with work or those who sit around unsure of what they can do. By keeping all tasks and currently-in-progress tasks in one centralized location, it can become very easy to find out what everyone is currently working on.

Here? Not here? Ghost teammates

Originally, we had a teammate that said that he was a designer. As such, although I am also a designer (among other things…), I thought that it would be better if I could help with the actual coding and leave the design to him. He seemed to be eager, so although I actually very much love design, I thought that it would be a good experience for him and handed the reins over gladly.

Unfortunately, things didn’t go so well.

The aforementioned teammate was in and out of the codeathon, coming late and staying only a few hours during the first day, then popping in late the second day and leaving early then as well. At the end, when he left the second day, he left us with half completed files and mockups that were merely a colored improvement over the wireframes. (Alright, perhaps my standards might be a bit high, but it truly was little improvement over the wireframes.) Another teammate later improved these, even learning Illustrator to do so, cleaning it up and fixing some of the excessive color. Now that is awesome. He did a pretty good job too.

But though it was better than what it was initially, at the end I still decided to take it upon myself to remake the mockups–all of them–and to redesign the logo…the morning of the final presentation.

All of this chaos could have been prevented by confronting the ghost teammate early on in the codeathon, setting deadlines for turning in the deliverables and about his absenteeism. One of the requirements of participating was that you could participate fully all three days—if you’re only going to be popping in and out, you shouldn’t be participating at all!

When confronted with this type of teammate, I feel like it would have been best not to have relied on him or to have given him quick and non-bottleneck tasks. It would have saved us a lot of wasted time waiting for him to provide us the mockups, trying to figure out what we should do next while waiting for the mockups, as well as the wasted time redoing everything he did.

Did we really need a flat design?

So waiting for the design mockups was a major bottleneck. But did it have to be?

Why were we even waiting for the UI design in the first place?

I think somewhere along the lines, we had all bought into the misconception that we needed the UI design first before we could do any coding.

This is just flat out wrong.

True, many times you have a “pretty” mock of a website or UI before you even start any coding. For some, it is because it is that they are more familiar with working with graphics before code: perhaps it may be easier to let their creative juices flow. But there are also some who prefer working in code from the very beginning, only using graphics program to make assets as we need them—like me!

I rarely ever make a “pretty” mock of a site before I start coding. Wireframes and sketches are usually enough for me to work with, and I only ever really need to have a pretty mockup if I had to present the site first to stakeholders. Honestly, I feel like it’s a waste of time, and it can be misleading since sometimes what is shown on paper might not necessarily match up to what the final product will actually look like.

In this case, there was absolutely no need for pretty mockups if we were actually going to code the app from beginning to end. It is simple enough to do the styling as we’re working on the frontend, and there were no stakeholders we have to get approval from before we start making the app either. From the beginning, there was no need to wait on our resident ghost to give us the design at all!

In a hackathon, it is completely unnecessary to do a “pretty” flat design first before starting coding. As long as you have wireframes and frontend developers that have a sense of design, you can just start coding right away!

Conclusion

So, in summary, what I’ve learned from this codeathon is that we should have:

  1. Narrowed the focus of the project to a minimum viable product and kept all product specifications and decisions to the same place.
  2. Set ground rules and finalized all organization-related decisions early on
  3. Used Scrum sprints to help keep the team focused, as well as a Kanban board method to manage todos so that everyone can be clear on what needs to be done and what is currently being done.
  4. Do not rely on ghost teammates, and if you must let them help, give them non-essential and non-bottleneck tasks only.
  5. Do not make a flat design before coding. Just leave the styling to the frontend developers so that they can start coding right away!

We didn’t win, but considering the hurdles and sidetracks we faced, we didn’t do half bad! At the end, we were not able to make a working demo (the codeathon facilitators said we did not need to do coding), but we had a great presentation and our app idea was very fleshed out. Heavens, it was a bit of a scramble, but we survived. Considering everything, it was amazing that we were able to put everything together at the end, and our presenter was also definitely the best. (Thanks David!)

In sum, it was an awesome experience and a great opportunity for learning. It was fun to figure out what everyone’s strengths were as we worked through the hackathon, trying to get our app idea solid. I think ultimately, the hackathon was a great chance to test your limits and to find opportunities for improvement. I was able to learn not only about working in a large group, but was also able to expand my experience from designing web apps to mobile apps as well.

I’m definitely going to be attending more hackathons if I can. A friend (also former teammate) and I have already applied for Citrus Hack taking place down in Riverside…Now it’s time cross our fingers and hope for the best!

One Reply to “Lessons from my first hackathon: Fight the Lady Killer Codeathon”

Leave a Reply

Your email address will not be published. Required fields are marked *