Code in the Dark: 5 takeaways for startups about how to treat your Devs

Oct 3, 2013
Vote on Hacker News

Code in the Dark

On September 27th I attended the first Code in the Dark event in Paris, put together by the Rude Baguette and the Tictail team.  I’ll admit I was quite dubious about the event before going but came back enthusiastic, impressed, and inspired.

The basic premise for the Code in the Dark is straightforward:  each round, developers have 15 minutes to replicate a specific web page. Because of the time limit, the emphasis is put on HTML and CSS though it’d be fun to see a “Code in the Dark Olympics” at some point with different technology and skills involved.

The main challenge at the event is the strict limitations put on the developers. Basically to stay within the rules, you can only use NotePad.  That’s right folks! No auto-complete, color-coding, or even preview.  You code blind for 15 minutes and hope that what you come up with resembles the layout.

While the event is definitely geared towards the keyboard virtuosos, it was also a great experience for those of us who are now more on the business side of tech.  Here are some key points from the event that you could use to improve your company’s tech team:

A well-fed dev is an effective dev

You will never go thirsty or hungry at a Code in the Dark event. I think we had enough food to feed a small country.  Though remembering how we used to always run out of Mountain Dew in our Boulder office, I think there is a direct correlation between a developers’ stomach and his productivity level.

Mo’money, No problems

If you have the funds, you have no excuse for not having a great front-end developer on your team right this moment.  Talking to the participants –including those who made it to the finals- many of them were not employed or were not working in a position where their skills were fully utilized.  If you are looking for talent, forget resumes, going to hackathons, or even paying recruiters. Just put one of these events together and see potential recruits work their magic live!

If you do recruit front-end devs, ask to see the code

I may loose followers for being so heretic but don’t trust someone who does not want to show you his/her code or feels insulted by being asked to code a few things in front of you. Why?  Simple:  It’s about fit, not talent.  There are tons of ways to code the same page –many of the contestants had specific approaches and techniques- yet what matters from a company standpoint is whether the code will be (re)usable long-term.  So when you are asking someone to look at what they’ve done, you are just asking to see how they think, work, and interact with others.

Set up the environment that works for your team.

I’ll come out and say it: Open floor plans are stupid.  Yes, I mean it.  I’d still rather have a quiet office where I can concentrate and focus without having to wear headphones to tune out noise.On the other end of the spectrum you have people who can code like virtuosos, listening to techno music, and wearing a Daft Punk helmet! (if anyone has the picture from the event, please share!)

Can you hear yourself think?

During the event I could see that the music and the sound volume distracted some of the contestants. That’s no big deal for a 15-minute rush, however consider the implications if you strive to put people in a position to succeed. Maybe having a flexible office space or even remote-work options could be a winning strategy for your business.

All the participants put on an incredible showcase. They should be commended for putting their skills on the line in an environment where the slightest mistake would mean elimination from the later round.  I really hope this format of events takes a hold and potentially grows into larger challenges involving different skillsets and maybe even pitting different companies against each other!

Regardless, Code in the Darks will be outstanding venues for those of us on the business side. We may not remember the difference between a <b> and a <strong> yet it does not mean we cannot learn simply by watching these developers in action.