Introduction

“Those who dare to fail miserably can achieve greatly.” — John F. Kennedy

This is exactly what I did – FAIL. And I did it fantastically! If there had been a category in the recent Chainlink Block Magic Hackathon for greatest for ‘Most Magnificent Mound of Muck’, I definitely would have been in the running for first prize. And to be perfectly honest, I knew that this outcome would be a possibility. So, what do I have to say for myself? I’m proud of all that I didn’t accomplish. Not only did I gain so much knowledge of building contracts in Solidity, I gained two new wonderful colleagues and I learned what NOT to do in a hackathon. Here are 10 of them.

1. The Argumentative Abyss

Lesson: Don’t allow argumentative members to corrode and stifle your team brainstorming.

In the midst of collaboration, dissent can be a double-edged sword. While healthy debate fuels innovation, a relentless argumentative spirit can derail progress faster than a runaway train. My team encountered this firsthand. As ideas clashed, our brainstorming sessions resembled a maze of dead ends filled with whole days of no communication at all. The solution? Don't spend your early days arguing about ideas. This isn't to say that there won't be disagreements, but the members of your team should be able to get on the same page early.

2. The Tortoise and the Telegram

Lesson: Don’t be slow with communication. Nail down your idea as early as possible.

Picture this: a slow trod of 'here and there' messages, each containing a nugget of brilliant notions. Meanwhile, our project idea remained elusive—a shape-shifting chameleon that defied capture. The lesson? Swift communication is the lifeblood of hackathons. Although we eventually corralled our ideas into a coherent vision, we had already lost several days. Having less that 50% of time remaining before the deadline, we were at a huge disadvantage to complete our project with anything near our true capabilities. Next time, I’ll sprint faster than a caffeinated tortoise to pin down our concept.

3. The Help Seeker’s Dilemma

Lesson: Don’t be afraid or hesitant to get help. Ask a lot of questions early and often.

Pride, thy name is “I’ll figure it out myself.” Armed with stubbornness and a stack of Stack Overflow tabs, I trudged through murky code. Spoiler: I got lost. The hackathon gods chuckled. The remedy? Swallow pride, ask questions, and seek help. There were so many wonderful people at the event, I didn't even much consider this option until it was too late. Lesson learned: Collaboration fuels innovation, and humility is the secret sauce. The fact that I already knew this and didn't take advantage still hurts.

4. The Test-Case Tightrope

Lesson: Don’t skip test writing to save time. It doesn’t.

In the adrenaline-fueled sprint toward submission, tests became the neglected stepchild. “Charlie, you need to do tests” the voice screamed inside my head. Turns out, we did. Our smart contracts, like a Jenga tower missing a crucial block, wobbled precariously. When the judges poke your code, it shouldn’t collapse like a house of cards. The moral? Write tests early, write them often, and treat them like your project’s lifeline. It will undoubtedly save a lot of time, as you'll be able to spot errors and weak points more concisely.

5. The Documentation Dilemma

Lesson: Don’t get lost in myriad documentation and tutorials. They breed confusion and doubt.

Solidity docs, Chainlink docs, YouTube tutorials—the rabbit hole beckoned. I tumbled down, clutching my sanity(the lack of sleep and overdose of caffeine didn't help). Amid conflicting advice and version mismatches, clarity evaporated. The antidote? A curated map: essential docs, trusted tutorials, and a pinch of intuition. Choose the appropriate doc for your tool and have faith in yourself that you can do what is needed. When in doubt, go back to number 3.

6. The Reluctant Decision-Maker

Lesson: Don’t be afraid to take on responsibility and leadership. If no one else wants to make a decision, then you do it.

For the first half of the event, our team waltzed around decisions like awkward teenagers at a school dance. Who’d lead? Who’d idea are we going to go with? Silence echoed. I wish I would have donned the mantle of reluctant decision-maker. I have experience in leading teams, so I know I have the ability. Imposter syndrome bit hard on this one. "I'm fairly new to coding, I shouldn't lead." How wrong I was. Had I stepped up and gave some supportive direction early on, I could have given my team at least another week for building our project. Look, somebody's got to be that person. If others are reluctant, step up to the plate. Just be sure to be decisive, but supportive and encouraging.

7. The Blueprint Blueprint

Lesson: Don’t start your project without a clear outline. This needs to be done early and will save loads of time in the end.

We coded like Jackson Pollock on a caffeine high—splattering ideas, hoping they’d coalesce into a masterpiece. Spoiler: they didn’t. The missing ingredient? A blueprint. A roadmap. A GPS for our hackathon odyssey. To be clear, we did have an outline. However, we didn't take the necessary steps to craft it before starting to code. It was more of a 'steady as she goes' approach. Next time, we’ll sketch our project’s skeleton and have healthy discussion about each point before diving into the code.

8. The Starting Line Mirage

Lesson: Don’t overly focus on the starting line. Visualize your end goal and work backward from there.

Picture a sprinter fixated on the starting blocks, oblivious to the finish line. Our hackathon journey mirrored this illusion. We obsessed over setup, syntax, and code. Meanwhile, our grand vision—RunBro became more of a moving target. Lesson learned: Start with the finish line. Envision the app in users’ hands, then reverse-engineer the steps. Sprint smart, my friend.

9. The Admin Ninja

Lesson: Don’t focus only on the code. You must have a team member who handles admin tasks.

In our coding frenzy, we neglected the mundane: README files, documentation, demo materials, and project hygiene. Enter the Admin Ninja—a teammate who wields spreadsheets, writes concise READMEs, and crafts compelling pitches. While some battle bugs, they battled bureaucracy. The result? A polished project that won't collapse under its own weight. Next time, we’ll recruit our Admin Ninja early.

10. The Joy Quotient

Lesson: Don’t forget to have fun. At the end of the day, nothing is more important than our health and the bonds we make with others.

Amid lines of code and sleep-deprived delirium, we stumbled upon a truth: Hackathons aren’t just about winning. They’re about forging friendships, sharing laughs, and celebrating small victories. Our joy quotient mattered more than any prize. So, as the clock ticked down, we high-fived, swapped memes, and reveled in our collective madness. Because in the grand hackathon tapestry, the threads of camaraderie are the most vibrant.

Conclusion

“Start by doing what’s necessary, then what’s possible; and suddenly you are doing the impossible.” – Bruce Lee

So, fellow hackers, embrace your magnificent failures. They’re stepping stones to greatness. As for me, I wear my “Most Magnificent Mound of Muck” badge with pride.