3 Lessons Learned from Hackathons…

There are days that I feel like I can do this software development thing, then there are days when I know I can, and then there are the times where I think I don’t know what I was thinking when I decided to make code life.

I think the difference in those days are the people who surround me. Usually I feel less capable when I am alone learning (failing) and it seems like there is no end in sight to get results.

As an introvert, it is very tempting for me to try and go it alone. But, I am keenly aware that I am at my best when I am on a team. Which is why when someone says “Hack-a-thon” I shiver at the idea of making myself vulnerable to a bunch of people who don’t yet know me. Yet, these challenges also excite me because “hack-a-thon” means that not only do I get to work on a team, but, as a team, we have to trust one another to get the job done. Why? Because there is no time to do much else but listen, learn, and trust one another.

Because of this, there is a lesson I have learned at each of the three hacks in which I have been involved. Each lesson building upon the last, and I find myself growing more as both a developer and a person. For some insight from me and others on what to expect at a hack, check out this post from Nashville Software School.

1. Humility

In my first hack, I was not accustomed to the dev team environment. I was able to do basic HTML, CSS, and JavaScript/JQuery stuff, but my team chose frameworks and languages that I had not yet been exposed to.

This hack required that the team come up with a concept and build the app based on what we decided.

I am a doer, but in this instance, I could only support my team in ways that left me doing very little in the app development process. I left our initial meeting feeling worthless, but I had to change my mindset so that I could be a contributing member of the team.

I provided ideas, encouragement, and snacks on demand as well as building relationships with the other devs. It was tempting to zone out and undervalue all of these non-techie contributions, but humility actually allowed me to learn by watching and asking questions.

I built great friendships on that first hack that are still very important to me today and I am grateful for the experience, support, and energy I was able to provide to my team even though I wasn’t really coding very much. We didn’t win, but we worked hard together so we learned a lot and grew as a team.

2. Belief in Myself

In my second hack, a couple months after the first, the environment was a little different. I was on a team of devs that were in my cohort at Nashville Software School. We had worked together before and knew each others strengths and played to those.

This hack was difficult because we had a smaller amount of time to build a full-stack app for a non-profit and chose to refactor code that I had used in my Nashville Software School front-end capstone. The idea came from our team lead and he trusted that my code was good enough to use for the purpose of the hack.

I felt really vulnerable with the team using my code since I didn’t think it was the best I was able to do, but since the majority agreed that it was perfect for our project, I had to get everyone up to speed on how I put it together and convince myself that I knew what I was doing when I developed it.

Often times we second guess our abilities, but the team members were excited and impressed by the code base I had provided and this made me very much aware that I was good enough to share my skills with other devs.

We won that hack and I will forever be grateful for learning that believing in yourself is the hardest, but it is also the most important thing to do.

3. Strengths-Based Development

My third hack (don’t worry, I am sure there will be MANY more) taught me leadership with a “strengths-based development” mindset. When I joined this team, I did so based on need. The non-profit we were assigned had a specific type of app that we were to develop and the leaders of the hack decided what type of devs were needed to complete the project.

We were given an option of front-end, back-end, and designer. We didn’t know who would be on our team only that they would have some experience in their chosen spot. I have worked over a decade as a front-end developer, so I chose front-end development as my contribution.

Little did I know that I would be the lead on the front-end as the other front-end dev was one of my current students, Dan. He is very strong in Javascript and CSS and I didn’t want him to have the same experience of little to no coding contribution I had in my first hack AND I knew I couldn’t pull this off alone.

While I could have chosen any JS library or framework like ReactJS or Angular, which would have played to my strengths, I decided rather quickly to do a JS/JQuery front-end with modularization. We used Browserify to modularize our code and Grunt to handle linting, unit testing, concatenating and minifying files.

I chose this for three reasons that I have already alluded to:

1. I needed help and as a front-end team of two, there was no question that we could code in JS,
2. I believe that strengths are important to capitalize on in a hack, and
3. To show that devs who code in JS well can make an amazing Single Page App too!

There is no time to learn new techs or get stuck in a framework that only one team member knows when there are literally hundreds of things that need to get done in a very short amount of time (36 hours in this case).

My strength wasn’t only the code though. Because I was able to capitalize on the strengths of my team, I was available to make space for my strength of positive energy so when we hit the low times, my positive energy could get us through those rough patches. We cabbage patched a lot during our dev process!

As the designers were laying out the app, I lead Dan through the user story and we began creating the app pages without the design. This allowed us to help the backend devs with data structure while also allowing us to discuss the endpoints that we would need to hit in the API they were creating.

Another benefit of not building an app that only played to my strengths was that I had more time to connect like sharing my passion of IT and software development with a group of girls from John Overton High School who attended so that they could see women can kick ass and take names too!

Oh…We won this hack too!

How do these lessons fit together?

The humility I learned in the first hack taught me to consider everyone involved in the team I was leading. The belief in myself from the second hack taught me that I could lead us effectively and efficiently through the process. Lastly, strengths-based development helped me to see that getting the non-profit an app that they can use with contribution from all team members was the most important part of the whole hack — not my own personal desires.

As a woman of color, it meant a lot to me to hold that last trophy in the air. I represent a marginalized group in tech and it is important that we learn that we can contribute to the success of a team regardless of how little we think we know. The point is to get into the game and give all you’ve got so that your team can succeed.

Will everyone agree with all the decisions that I made? Probably not, but they weren’t there grinding with us and my teams were on board with my decisions and that is really all that matters in the end…that and winning whether a trophy is involved or not.

[asig]

Dr. T

Hello! I am Dr. T, developer and educator, who helps learners embrace their missions by activating their developer superhero within! You are the hero who you have been waiting for.