• Ten Protips on Avoiding Hackerthon Fail

  • 해커톤 실패를 피하는 전문가의 10가지 팁

  • Delyn Simons is VP of Developer Platform for Mashery (a ProgrammableWeb sponsor). Delyn previously worked in developer community for eBay and still believes that people are basically good.
  • Delyn Simons는 Mashery (ProgrammableWeb의 스폰서)에서 개발자 플랫폼 부분을 담당하고 있다. Delyn은 eBay의 개발자 커뮤니티에서 일을 한 경험이 있으며 지금도 사람은 기본적으로 선하다고 믿고 있다.
Image of 878 article
  • Our Mashery Developer Outreach team co-organized and participated in over 50 hackathon events in 2011. Not yet 3 months in to 2012, we’re already up to 25 and counting.  All this exposure to hack events over the last 2 years has given us a lot of insight into what makes for a great hackathon. This insight also helps us  – and our Enterprise/Fortune 500 customers — avoid the non-awesome ones.
  • Mashery Developer Outreach 팀은 2011년에만 50번도 넘게 해커톤 이벤트를 공동으로 조직하거나 참여했다. 2012년을 아직 3개월도 넘기지 않은 지금에는 이미 25회에 달하고 있으며 더 늘어날 것이다. 지난 2년동안 해커톤 이벤트를 진행하면서 무엇이 훌륭한 해커톤 이벤트를 만드는가에 대한 많은 영감을 주었다. 이러한 영감들은 우리들이 -- 그리고 우리의 기업/Fortune 500 고객들이 -- 그저 그렇고 그런 이벤트를 피할 수 있도록 도와준다.
Image of 878 article
  • Ready. Set. Go.
  • 준비, 시작!
  • #1: No Powerpoint. Ever.
  • #1: 파워포인트는 절대금물
  • Decks are for Suits. Nothing kills hackathon spirit quicker than watching teams present a concept Powerpoint better suited for an MBA class.
  • 파워포인트 슬라이드는 양복 입고 일하는 직장인들을 위한 것이다. MBA 계층에나 어울리는 파워포인트로 아이디어를 설명하는 것만큼 해커톤 정신을 죽이기 쉬운 건 없다.
  • #2: Icebreaking for Introverts
  • 내성적인 사람들과 안면 트기
  • Hackers socialize a little differently. One of the benefits of hackathons is encouraging teams to form onsite with complementary talent. Help foster a sacred place for collaborative coding. Host a pre-event hackathon meetup to help form teams based on common interest. Offer some type of shared development environment to help with group commits, such as GitHubHeroku, or DotCloud.
  • 해커들은 일반인과 좀 다른 성향의 사회성을 갖고 있다. 해커톤의 이점 중 하나는 현장에서 각자의 재능으로 다른 사람을 보완할 수 있도록 팀을 구성할 수 있다는 것이다. 도움은 해커톤 행사장을 협업 코딩의 성역으로 키워낸다. 해커톤 행사 전에 공통의 관심사에 따라 팀을 구성할 수 있도록 모임을 주최하라. GitHub, Heroku, DotCloud와 같이 그룹 커밋이 가능한 몇 가지 공용 개발 환경을 제공하라.
  • #3: Your Hackathon is a Reflection of your Culture
  • 당신의 해커톤은 당신(회사) 문화의 반영.
  • Branding, Events, Marketing, Legal, Corp Comms teams are stakeholders, not hackathon organizers. Sometimes we all find ourselves in awkward conversations with teams who have never thrown a hack event before about wanting the event to reflect an “exclusive branding presence.” Stand your ground. Hackathons are not a branding exercise. Hackathons are not about who has more prominent logo placement. Hackathons are not a photo opp for your boss’s personal campaign to appear more “innovative.” Hackathons are about your company culture of participating with developers, and listening to other companies who offer APIs that developers can remix in new and interesting ways. If your culture tends toward braggadocio, err toward humility and dialogue.
  • 제품이미지, 행사, 홍보, 법률, 기업통신팀들은 해커톤 주최자가 아닌 이해당사자들이다. 가끔씩은 우리모두가 한번도 헥(데이) 행사라곤 벌여본적이 없는 팀들과 "전적으로 제품이미지 형상화"을 반영할 행사를 바라는것에 대해 어색한 대화들을 하고있는 우리 자신들을 발견한다. 해커톤은 제품 이미지화가 아니다. 해커톤은 누가 더 특별 대우를 받는지에 관한것이 아니다. 해커톤은 보다 획기적으로 비춰지기 위한 당신 상사의 사진 찍어둘 개인 홍보의 기회가 아니다. 해커톤은 개발자와 참여하는 당신 회사 문화에 관한 것이며, 개발자가 새롭고 흥미로운 방법으로 재사용할 수 있는 API들을 제공하는 다른 회사들로부터 들을 수 있는 곳이다. 만약 당신 문화가 허풍의 경향이 있다면 겸손과 대화란 오류를 범해보라.
  • #4: Co-organize with kindred companies
  • #4: 관심이 비슷한 회사들과 공동주최
  • Why is your company throwing a hackathon if you don’t have an API or developer resources? Without naming names, we’ve seen a rash of “premium brands” racing to attach themselves to developer events. (See tip #3) First, have an API that makes it easy get started with interesting data. Then, partner with other companies who also invest in tech talent to represent their company at hack days. These evangelists also need to be excited about actively mentoring developers on your resources to help them build faster and move forward. Work on attracting great partners and complementary data. Solo is hard unless you are Google or Foursquare.
  • 만약 당신의 회사가 API나 개발 리소스가 없다면 왜 해커톤을 개최하는가? 이름을 댈 필요도 없이, 우리는 많은 "유명 브랜드"들이 자신들을 개발자 행사와 엮어보려고 달려드는 것을 봐왔다. (팁#3) 먼저, 흥미로운 데이타로 쉽게 시작 할 수있는 API를 가져라. 그러고 난 후 핵 데이(hack day)에서 자신의 회사를 대표할 기술 인력에 투자할 다른 회사들과 파트너를 맺으라.
    이 전도사들 역시 개발자들이 더 빨리 만들고, 일을 진행시킬 수 있도록 돕는 자발적 맨토링에 열이 나 있어야한다. 인기있는 멋진 파트너와 보완적 데이타를 찾기위해 노력하라. 당신이 구글이나 포스퀘어가 아니라면 혼자 하는 것은 어렵다.
  • #5: Plentiful Powerstrips and Pipe
  • #5: 충분한 파워코드와 인터넷을 준비하라
  • Have you been to an event with 150 developers trying to get online and can’t? We have. Don’t be that hack event. Make sure your Wi-Fi SSID/password is easy to access (just say no to the 20-digit hexadecimal guest password for this event). Have boosters and repeaters that help the advertised upstream and downstream speed be the reality — everywhere in the room. Run stress tests. Don’t take your pipe for granted with this crowd.
  • 150명의 개발자가 온라인에 접속하려고 해도, 할수 없었던 이벤트에 가본적이 있는가? 우린 있다. 당신의 해커톤이 그런 이벤트가 되게하지 마라. Wi-Fi SSID/패스워드를 쉽게 받을 수 있게 하라 (20자리 16진수 손님용 비번은 안된다). Wi-Fi 부스터와 리피터를 충분히 설치하여 실내 어디에서든 업로드와 다운로드 스피드가 홍보했던 것처럼 나오게 하라. 스트레스 테스트를 해보라. 이벤트 참가자들이 몰려들었을 때 여러분의 인터넷 대역폭이 여유 있을 것이라고 믿지 마라.
  • #6: Have as few rules as possible – but enforce the ones you do
  • #6: 가능한 적은 규칙을 가져라- 하지만 정한 규칙은 반드시 지켜라
  • We’ve witnessed teams in front of judges try and pass off a polished application that took weeks to build as something they just spun up in 8 hours.  We’ve sat through two hours of 15-minute sponsor API pitches before hackers were allowed to begin coding. We’ve looked on in horror as teams blow past the announced 3-minute demo limit and no one stops them from droning on for 10-minutes. Hacker event etiquette and norms are pretty well established by now. Try and have as few rules as possible, but be prepared to vigorously enforce ones that ensure a level playing field and a good time for the group.
  • 우리는 일주일 넘게 걸려서 만든 잘 다듬어진 어플을 방금 8시간 만에 만든 것처럼 심사위원들 앞에 제출하는 팀들을 보았다. 해커들이 코딩을 시작하기 전에 하는 15분짜리 스폰서 API피치를 2시간 동안이나 하는것을 앉아서 지켜봤다. 3분 데모시간을 아무도 지키지않고 모두 10분넘게 지껄여 대는것을 두려움 속에 바라봤다. 해커 이밴트의 에티켓과 규범은 이제 어느정도 잘 다져져 있다. 가능한 적은 규칙을 갖도록 노력하라. 하지만 공정한 경쟁과 팀들이 좋은 시간을 갖을수 있도록 몇몇 규칙들은 강하게 규제할 준비 해야 한다.
  • #7: The Most Common Hackathon Faux Pas We See
  • #7: 해커톤에서 보이는 가장 흔한 실수
  • Don’t allow teams to repurpose an existing app, add a feature, then flog their badly disguised company pitch as a hack. See tip #6.
  • 이미 만들어진 앱에 기능만 조금 추가하는 식으로 핵(hack)으로 가장한 회사 피치를 용납하지 마라. 팁#6 참고.
  • #8: More Science Fair, Less Business Plan Competition
  • #8: 사업계획서 경진대회가 아닌 과학 박람회
  • The pitch itself should succinct, engaging, even funny — but it must involve a prototype. There are those who sell and those who create. Make something.
  • 피치 자체는 간결하고, 매력적이며, 재미도 있어야 한다. 하지만 프로토타입이 수반되어야 한다. 만드는 사람 따로 있고, 파는사람 따로 있다. 만들어라.
  • #9: Create a Hacker Haven
  • #9: 해커들의 천국을 만들라
  • Caffeine, snacks, comfy chairs, headphones, background music to camouflage the keyboard clackety-clack. Celebrate the technical talent who has gathered at your event, and honor their hours of work they are putting in at your event. This gathering of highly sought-after knowledge to work with your data and tools is a gift. It’s also an open secret that most attempts at virtual hackathons fail from lack of participation. In an era of continuous partial attention (thank you, Linda Stone) and connected devices, the most powerful magnetic force is the magic that happens being there in person.
  • 카페인, 먹거리, 편안한 의자, 헤드폰, 키보드 두드리는 소리를 가려줄 배경음악. 당신의 이벤트에 모인 재능있는 엔지니어들을 축하하고, 그들이 이벤트에서 많은 시간을 들여 한 일들을 존중하라. 요즘 잘나가는 지식이 당신의 데이터와 도구들을 가지고 일하기 위해 모였다는 것은 선물이다.대부분의 온라인 헤커톤 시도는 참여부족으로 실패한다는 사실 또한 공공연한 비밀이다. *부분적 관심 지속과 (인터넷에) 연결된 기기들의 시대에, 가장 강력한 자력은 실제 그 공간에 있을 때 생기는 마술이다.
  • note icon
    *부분적 관심 지속- 한가지 일에 집중 하는 것이 아니라, 여러가지 일들에 동시에 관심을 갖는일
  • #10: Your Hackathon is not a Frat Party
  • #10: 해커톤은 대학교 사교 모임이 아니다.
  • Give respect, get respect. And don’t start serving beer until an hour before submissions are due. #apijamfail
  • 상호 존중하라. 그리고 제출 마감 1시간 전까지는 술은 마시지 말 것. #apijamfail
3 Comments
umteeh

umteeh • Apr 4th, 2012

@ikpark 팁#5 에서 pipe를 인터넷으로 봤는데 맞는건가요?
  • umteeh • Apr 6th, 2012

    @ikpark 감사합니다!

  • ikpark • Apr 5th, 2012

    @umteeh 예, 적절한 선택인 것 같습니다. 리뷰도 해야 하는데 예상보다 진도가 느려지네요. 제 대신 번역 많이 해주셔서 감사합니다. :)