Greek mythology tells us the story of Sisyphus, a former king of Corinth who was condemned by the gods to an eternity of physical and emotional torture. His punishment? Pushing up a large boulder up a hill every single day, only for that boulder to roll back down to the hill when the task was seemingly completed.
Only fools and theoretical physicists would envy the nature of his punishment. He toiled away under the scorching heat of the sun daily, directing his efforts towards the achievement of a single goal; a goal which, by the decree of the gods, was unattainable. Surely, Sisyphus must have been an unhappy man. But was he?
In 1942, a certain man named Albert Camus wrote an essay, “The Myth of Sisyphus,” in which he dismissed the theory of a glum Sisyphus. Mr. Camus, who happened to be a Nobel laureate, argued that the mythological figure was indeed a happy man. Why? Because “the struggle itself…is enough to fill a man’s heart.” In layman terms, Camus was essentially saying that joy is derived from the process of doing.
What, then, do Greek mythology and the opinion of a Nobel laureate have to do with hacking and hackathons?
A lot of the code you write at a hackathon would probably not end up in the final iteration of your hack. Your hardware hack, at times, might begin to resemble an exercise in futility. Participating in a hackathon can seem like a sisyphean undertaking, especially to novices with sparse or no programming experience. This, I believe, is why many non-coders I have spoken to have been apprehensive about going to hackathons. Myths surrounding hackathons have disseminated fallacies about insurmountable challenges requiring herculean feats of heroism (in this case, awesome coding skills) in order to succeed. Despite the explosion in the popularity of hackathons in the last half-decade, a lot of people out there still believe that hackathons are competitive events for code monkeys. According to their logic, the absence of coding ability is a barrier to participation. A hackathon attendee without coding skills is an embarrassment, and thus, has no “shot at victory.”
The very existence of these myths points towards a sizeable problem: a fundamental misunderstanding of why people hack.
The most important takeaway from any hackathon should be the experience of participating in one. Any seasoned veteran would tell you that, in retrospect, you would cherish the long hours spent working on your project and the joy of meeting hackers from other schools more than any success which your project may enjoy. Yes, prizes are handed out at the end of most hackathons, and, yes, some team would walk away with “Best Hack” and a few thousand bucks. That said, no one really cares, nor should you (unless you’re a megalomaniac). Hackers hack for the sake of hacking. It is “the struggle” of cranking out a project that makes hackathon attendance worthwhile, not the acclaim or prizes which a hack may receive.
Anyone can go to a hackathon. You don’t need to be GeoHot, nor do you need to know that Ruby is actually a programming language. If you don’t know anything about code, you will learn all you need to know about code there, but only if you want to. Purists will argue that a hackathon is a more effective way of learning how to program than sitting in a dull, dreary classroom; many will wholeheartedly agree. For someone without a programming background, a first hackathon can be a nervy affair. Learning a programming language in a faced paced environment and using that newly acquired knowledge to make a hack can be challenging, but that doesn’t mean that it’s impossible. After all, everything is hard before it becomes easy.
If you’re still dithering about going to a hackathon, you should probably come to Bitcamp. You’ve missed out on a lot already. Don’t miss out on more.