

How Jetpac Built a Photo Quality Algorithm for $5k in 3 Weeks - datageek
http://www.readwriteweb.com/archives/how_two_startups_used_games_to_beat_the_developer.php

======
humbledrone
The 60 second challenge thing strikes me as extremely short-sighted. It _is_
impressive to be able to solve a series of tiny bugs with just 60 seconds for
each one, but I don't think it's the right metric to find the elusive "10x"
programmer.

It's my opinion that "10x" programmers are an order of magnitude faster than
their peers not because they are lightning-fast at spitting out code (although
they may be). They're faster because they can analyze the problem, drill down
to its essence, and come up with an effective plan for solving it. Contrast
this with a poor programmer, who might code circles around the problem,
wasting time writing code that could just be taken from off the shelf. It
doesn't matter if the poor programmer somehow is brilliant at punching out
correct code if the code they're punching out didn't need to be written in the
first place.

It's like selecting creative writers by holding a contest to see which ones
can spot a grammatical mistake the most quickly. Sure, that's a helpful skill
for a writer to have, but it doesn't mean that they'll write anything worth
reading.

~~~
kkowalczyk
Or we can assume that the company that does the hiring via 60 second challenge
is not ran by complete idiots and they do keep track whether those hires end
up being effective employees for them. Let's give them the benefit of a doubt.

Your argument seems to be that there are only two possible programmers:
effective designers that are slow to code or fast coders that are bad
designers (designer in terms of code architecture, not graphic design, of
course).

I claim that there are no good architects that are slow coders i.e. all good
architects are also good coders.

When you look into research of skill acquisition, or even common sense, in
order to become good at something you first have to master the basics before
you master higher-level skills.

In the field of programming, being able to implement a piece of highly
constrained code are the basics of our craft.

Once you're really good at that, people move up to tasks that have less
constrains and are therefore high-level: choosing an implementation language,
designing how pieces of the whole app fit together etc.

But you won't ever get to do that if you were not able to quickly and
confidently implement a function that someone else specified, just like there
are no chefs who can't cut vegetables very quickly or basketball players that
are brilliant tacticians but can't run very fast etc.

Mastery of basics is not a guarantee of mastery of higher-level skills but it
is a prerequisite.

~~~
humbledrone
> _Or we can assume that the company that does the hiring via 60 second
> challenge is not ran by complete idiots and they do keep track whether those
> hires end up being effective employees for them. Let's give them the benefit
> of a doubt._

You don't seem to be aware of just how disastrous a bad hiring decision can
be. The direct financial cost is easily in the tens to hundreds of thousands
of dollars, depending on how long it takes to identify their poor performance,
warn them, and finally fire them (all the while documenting their performance
rigorously to avoid frivolous lawsuits later on). Beyond that, the opportunity
cost of having a poor programmer in place of an excellent one is even worse.
It is far, far better to avoid a bad hire in the first place than to catch
them later.

> _Your argument seems to be that there are only two possible programmers:
> effective designers that are slow to code or fast coders that are bad
> designers (designer in terms of code architecture, not graphic design, of
> course)._

I'm sorry, but you wrote a lengthy rebuttal to an argument I never made. Read
my comment again. When describing the "10x" programmer, I never said that they
_had_ to be a slow coder. In fact, I explicitly said they "may be" lightning
fast. My actual argument was merely that the most dramatic improvements in
software construction speed are due to making better decisions about what to
code, what tools to use, how to approach the problem, etc. And, in my opinion,
the benefits of making good decisions about these things absolutely dwarf the
benefits of being able to slam out the code in record time.

------
waitwhat
Spoiler: The algorithms actually work by doing text analysis on the captions
and other metadata, and no actual image analysis.

~~~
datageek
the algorithm needed to execute quickly. image analysis takes too long.

~~~
kabdib
What's the bottleneck? Bandwidth for downloading images? Understanding of an
algorithm that would do the job?

~~~
petewarden
Bandwidth and general cumbersomeness of dealing with larger amounts of data
with starving-startup resources. I actually spent about a decade of my career
focused on image processing, and while I love it's power, I knew how much of
an engineering challenge it can be at massive scale. I need to do a blog post
about this, since I know my choice is a bit surprising and needs explanation.

------
brown9-2
Is 30,000 photos a large enough dataset for a ML exercise like this?

It might just be journalistic simplifying but I wonder if they overfit their
data with such specific "good" and "bad" words:

 _Among the best words: Peru, Cambodia, Michigan, tombs, trails and boats.
What photo captions are the most likely to signify a bad photo for a travel
magazine? San Jose, mommy, graduation and CEO, Warden says._

------
Iroiso
The essence of the post is about using crowd sourcing to alleviate start-up
challenges, I think they did a good job of exposing these opportunities to
founders, (BTW, its also great PR for kaggle), Good Article all in all.

~~~
coderdude
I'm not sure why you were down-voted at least a couple times for this comment.
You've done a much better job of summarizing what this article was about than
the "spoiler:" above (which is more based on the title than the point of the
article).

