From October 4th to October 7th, around 60 individuals participated in a hackathon in Winnipeg, titled "Builders League," with this project focusing on "Community of Big Hearts." I volunteered during this event, starting as a "Code Wizard" and finishing as a "Tech Lead." While not a traditional hackathon, overall, the project was a success. In the spirit of improving, here are my key takeaways from this intense weekend of collaboration among 60 people of varying skill levels who hadn't necessarily worked with each other beforehand.

The project has a single aim, the contributors have many goals

It's essential to establish the project's aim and ensure everyone knows what they are working towards - or is it?

A running joke this weekend was that, until the final presentation, I didn't know what the project was. Personally, I missed a critical meeting, but I saw many other contributors who had some unanswered questions about the big picture. This, however, was not a big issue in development because the organizers made detailed documents about the project and shared relevant parts with each contributor, with the whole document available for anyone interested.

While the group aims to finish the project, realizing that individuals also have personalized goals is important. One might want to learn a new technology, one might want to show their skills, and one might want to practice teamwork. It falls to the organizers to plan how different goals would align with the overall project and help people achieve their goals as they move the project toward the final goal.

A natural follow-up to this thought is that individuals with different goals require different resources and information. Information that might be beneficial to a group will mentally exhaust another. Suppose someone knows how to work with a technology and wants to show their skill. In that case, it will only frustrate them to sit through a tutorial instead of being productive, and this further goes against their goal - knowing that after the tutorial, it's less impressive that they knew how to work with the tech beforehand.

So, while we can have long meetings going over every detail and make sure everyone is aware of the project, a better approach might be to keep the meetings to a minimum update while having the detailed documentation accessible for anyone who might want more info.

The key takeaway is that long meetings with everyone involved waste time and tire the contributors. Instead, they should be replaced with short meetings with everyone and frequent check-ins with contributors to ensure they have access to the resources they might need.

The project has features, the features have tasks

This weekend was planned to have multiple phases, where each phase would build upon the last, finishing with the final working project on the final phase. Don't get me wrong, this is doable, but it requires intense planning and teams to be on the same skill level. As previously mentioned, the organizers did a fantastic job of planning the details of the project, but teams had many varying skill levels. What makes this harder is that the different phases require different skills as well, so if you knew react, you might be able to build one phase, but then the next one would require you to work with a database that you haven't used before.

Halfway through the weekend, we moved away from this system. Beginning by breaking the project into features, and grouping them by their importance. A must-have set was selected, and we put the rest behind locked milestones. This way, if we run out of time, we will still have a functioning product with some incomplete features instead of an uncompleted project.

The features still had a task list that should be done in order, but we allowed contributors to focus on the ones they were confident in doing. We frequently check in to make sure the base features aren't blocked. If they were, we would ask contributors to work in groups or give them appropriate mentors, but let's discuss that later in another section.

What happens if someone doesn't feel confident working on any available features or tasks? We introduced a bounty system where individuals could submit various fixes, such as style fixes in the UI, bug fixes in the logic, or even broken links. Reporting a problem and solving it both had points, and I was thrilled to see one of the contributors won a phase mostly because of the fixes they submitted!

Adding the bounty system had two other effects; first, individuals who were there to learn and feared they might not be able to contribute as much and would end up reading other members' code and trying to find holes in them - I can't stress how effective this strategy is for learning new technology. Second, this allowed us to accept imperfect solutions to a task - if a solution mostly works, we could accept it to unblock tasks dependent on it and leave it to a bounty hunter to perfect it.

Contributors have questions, mentors have specialties

From my perspective, many efforts were wasted initially when mentors, myself included, would try to solve all problems by themselves. While it's true that I can spend a few minutes reading the errors, a few minutes reading the relevant part of the code, google up documentation, and read it for a couple of minutes to find what might have gone wrong, it's much better if I acknowledge that my time is better spent doing something else and find a person who knows the system.

To prevent wasting this effort further, we divided the project into various areas of expertise, assigning mentors to each group. After that, when someone had a problem or question that we couldn't immediately solve, we would refer them to the expert in that area instead of trying to find a solution on the spot. Though this isn't a perfect solution, it allowed us to move the project forward.

Tasks have (flexible) deadlines, the project has an end

As Parkinson's Law states, "work expands to fill the time allotted for its completion." If you allow six people to spend five hours on a task that one person can realistically do in half an hour, it will take thirty person-hours and still need that one person to spend the half hour fixing it. This isn't necessarily a problem; having six sets of eyes on an important task ensures that more aspects of it have been analyzed, and there should be fewer issues. Still, when your most significant limiting factor is time, you should take a different approach.

Instead, we assumed every task could be done in ninety minutes. Checking in frequently with the contributors, asking them to take on what they think they can finish in the next ninety minutes, and extending the deadline or adding contributors only if necessary. This turned out to be a great approach, and there were only a few instances where we needed additional hands onboard.

Another important aspect is that the project should end at some point. So how do you prepare for it? A common practice in open-source communities is to have release candidate branches where features are frozen and only fixes are applied. Contributors are encouraged to continue working on new features and adding things to the system, but we will assume they won't be ready in time for the "release," which in this context is presenting it to various people.

Final thoughts

I really enjoyed this weekend, and I'm looking forward to other hackathons. While I don't mind seeing experimental hackathons like this one, I still like traditional ones where groups compete to provide solutions to common problems.

I would like to sincerely thank all the organizers, contributors, and sponsors who made this happen. It was indeed a wonderful experience!