Hackathons

Why am I against them.

I consider hackathons a waste of time and energy.

It is not about length constraints. It is about the attitude.

I don’t enjoy building small things. I prefer the big ones to come from underneath my fingertips.

Big things are demanding.

• They require thorough thinking.
  In the order of hours, at least.
• They may require research.
  In the order of days, easily.
• They may require good understanding of what current and soon-to-come technologies fit well.
• They require understanding of how and where do they fit the world.
• They often call for several conversations with many people.
  Who, in their turn, are often busy enough with their own big things.

Hackathons, the way I understand them, are the exact opposite:

• Doesn’t matter if it does the real thing.
  It looks sexy. Ship it.
• Doesn’t matter if it is well engineered.
  It somehow works. Ship it.
• Doesn’t matter if it is about to be thrown away next week.
  It was not supposed to live long anyway. Now ship it.
• Doesn’t matter if it does not sustain any constructive criticism.
  People who are capable of providing it would rarely show up for a hackathon.
  Those who do show up would usually have the attitude of … you guessed right. “Ship it.”

I perceive the culture of hackathons to be a desperate move in an attempt to find someone who can at least code something.

Those, who can build real things, are already busy doing that. Most of the people who remain uncertain are those unwilling to or incapable of thinking big.

True, a hackathon is a good way to gather those people together. The community, however, is unlikely to interest me.

Furthermore, I find no emotional attachment to short-term results one can demonstrate during a hackathon.

• I don’t need to see or touch “something that is alive”.
  My vision and imagination are good enough to well understand what is about to happen.
• Unless it’s a major outage, whether it takes or day or a week is almost irrelevant.
  Whether it lasts for three weeks, three months or three years is what counts at the end.
• I care for long-term solutions and think of any “hacked” code as technical debt.
  To provide a contrast: I would rather spend a day writing a nontrivial test for a feature that is likely functioning right as it is right now.
  To be sure, for today and for tomorrow.
  Because bugs do happen.
• I think and act on a scale of products and projects.
  Not technologies and tools.
  A day spent in talking with the core team and drawing prospective designs on the whiteboard is more productive than a day where “those two new technologies we always wanted to check out” got checked out.
• I have bigger things going on.
  While I agree that a hackathon boosts overall efficiency on a scale of several dozen hours, I also believe this efficiency is not “created” out of nowhere, but is rather being “borrowed” from past and future productivity.

Hackathons have their place.

As a networking event. Essentially, as an addition to free beer and pizza. Or as a good reason for them.

For hiring reasons to an okay-but-not-too-great of a company. As a team event. To help kids to get into programming, omitting the beer part. To get everyone off their main work to do something exciting for a short while.

But I don’t support all the excitement people seem to have about hackathons these days. And encourage experienced engineers to share this approach.

Originally published on Quora: http://dimakorolev.quora.com/Why-Might-Someone-be-against-Hackathons