
How to hire a programmer to make your ideas happen - dwynings
http://sivers.org/how2hire
======
city41
I am the developer in this situation right now. I was hired by a small company
as their sole developer to write them a program. So far, I have to say I
pretty much disagree with everything said here.

I think the developer really needs to know the details of the domain and
problem space. The company I am working for is a workforce management
consulting firm. The first week on the job I interviewed 10+ consultants with
the company. Got to know their tasks, goals, accomplishments, needs and pain
points. I also shadowed in on one consultant for a day, and read a lot of
literature. I know an awful lot now what it means to do work force management
and workforce management consulting. This is helpful, very helpful. I become a
knowledgeable user of the very system I am creating. Imagine if Adobe's
developers had no clue about image editing, Photoshop would have been a
disaster.

This feeds into my other point. Don't give the developer detailed descriptions
of every click, button, error, etc. Give them the exact opposite. Tell them
what the system needs to accomplish, and let them design it. For one, they
will almost certainly design a simpler and easier to manage system than you
will (maybe not easier to user, because let's face it, that's not usually a
programmer's forte). Since the developer now knows the domain pretty well,
they can use that knowledge to help design an effective solution. let the
developer arrive at your goal with as minimal amount of code and work as
possible. That way you can see your vision in the flesh, use it, and actually
start to understand what it does. Only once a feature is actually implemented
and put to use do you really start to understand what it needs to do.

Maintain a dialog with your developer. Give feedback often and have the two of
you work together on where the project is going.

Basically all I am saying boils down to what most agile development processes
ascribe to.

I do however totally agree with doing the "simple" version 1.0 release first.

~~~
ryanwaggoner
You sound like a great developer, but the reality is that you're an anomaly.
Most developers suck, especially the ones on elance, rentacoder, etc. And if
you're not technical, _you have no idea how to figure out which ones suck._ So
I see this advice as being for non-technical folks who want to maximize their
chance for success and limit their downside. And in that light, I think it
succeeds.

~~~
pier0
That and the fact solo founders or non technical people with an idea don't
already have 10 or more consultants working for them.

~~~
city41
But then isn't this all a recipe for disaster? If you need a piece of software
to be written from scratch for you, then it's probably critical to your
business. It may even literally be your business. Why in that case would you
want to scrape by with a crappy coder and try and wield them to be effective?
I think if that is the situation you end up in, you're better off not doing it
at all.

Granted I've never done a start up, so maybe I'm just naive. But it seems like
if you want to do a technical start up, you should be technically minded.

~~~
webwright
"If you need a piece of software to be written from scratch for you, then it's
probably critical to your business."

G'lord, no! How much software is necessary for the minimum viable product of
Groupon? Digg? TechCrunch? Facebook? Twitter? FourSquare? StackOverflow? Heck,
we KNOW that Digg was outsourced, and that worked out okay. Many (maybe even
MOST) startups true problem is marketing/UI/social rather than deep geekery.
Many more can get by on half-assed engineering to prove out the initial
assumptions and then just rewrite if they see a glimmer of success. Paul
Buchheit has said that he rewrote chunks of Gmail quite a few times... It's
not unusual.

There are plenty of startups where this would be a disaster but (as web apps
get easier and cheaper to build) I think they are increasingly the exception
rather than the rule.

------
sivers
Assuming most HN readers don't need this advice for themselves.

But if you disagree with it or think I left out something important, please
consider leaving a reply in the comments on that page, so future readers will
see your suggestions, too.

~~~
Alex3917
The way I was taught was to start by hiring several designers to design every
screen, and then only hire programmers after you're completely satisfied with
the design. The way these outsourcing firms get you is by offering a cheap
bid, and then charging you every time you want to make a change. So start out
by knowing 100% what you want, and then once they've accepted the project
don't let them ask any questions or make any suggestions until 1.0 is
completely finished. (If they don't understand something they can ask for
clarification, but that's it.)

Always have your fights up front, never once the project has started. That way
you'll get the project on time and under budget.

~~~
kls
Right get the UI right and it won't cause as many iterations on the back end
(where it hurts more) as well prototype the whole UI in HTML/Javascript,
Flash, Desktop app, whatever suits your fancy. Have a fully functioning UI
that the user can touch and feel before you develop the back end. This will
flesh out all data requirements and business logic services that will be
needed to support the UI.

I am a little leery of not allowing the developer to provide input though.
Things are going to change, you just want to narrow those changes to the
important things.

~~~
ams6110
I don't think you need a finely polished UI to start with, but some wireframes
or even hand sketches of what each page/screen/dialog will look like can be a
very effective communication tool. Written use cases are great but a picture
can truly be worth 1000 words.

~~~
kls
End users think in terms of screens, if you can provide them with a fully
functioning ui then you can get valuable feedback about useability up front.
The client knows in short order that they are getting all of the features they
want because the get to touch and feel the system. After I adopted this method
my project change orders slowed to a trickle.

------
drewcrawford
Regarding the overall "numbers game" approach, it will work, in the strict
sense that the client will get what he asked for, but not in the sense that he
will get what he wants.

Most people, when they try to hire me (although they don't realize it) are
looking for technical or domain expert feedback. They may think they need
such-and-such coded, but in reality they have a business problem that they
need solved. More often than not, I can weasel out of them the business
problem, and the technical solution to solve it, and it's often not at all
what they originally wanted to have me do.

Part of it is that clients vastly overestimate the development time of some
types of features, and vastly underestimate the complexity of other types of
features, so they cut the wrong stuff from their MVP. In a sense, their
project is doomed before they even hire a programmer.

Top technical talent can get and keep you on course in a way that will fix
problems you don't even know you have.

------
snh
Granted, detailed requirements are good. But many - if not most - clients are
unable to write a requirements document on their own. So it becomes part of
the contractor's job to help them develop the requirements.

I've seen a number of cases where the client spends a lot of time writing
detailed requirements that are technically infeasible. They may not realize
that in their simple "if x then y" statement, x is actually the result of a
fifty step process involving a unicorn and a carebear making sweet love.

~~~
christonog
Just curious, in what instances have you experienced a client request
something technically infeasible? What was the feature or project?

------
shib71
I like the idea of getting multiple teams to take on the first milestone, and
not just because it a good long term strategy. As a contractor I frequently
encounter clients who have unrealistic expectations. This process would give
someone new to the industry a more realistic idea of the range of skill and
the difficulty of the work.

------
Tichy
I actually don't believe in detailed requirements or specs anymore. It is
never possible to think of all issues beforehand. I am also not sure if they
are really good for the client. Sure, it helps when negotiating fixed price
contracts. But that also means that you will only get what was negotiated. If
the developer has a brilliant insight while coding the thing, he'd better not
tell you about it if he doesn't want to mess up his time calculations.

------
pier0
Based on my own experiences using marketplaces to find freelancers, as long as
the project posted is well defined, it is much better to have the coders
submit bids for the total.

Every single time I paid by the hour I have had problems. I understand Derek's
advice is to find one coder to work on a large project. But even then, IMHO is
better to start with a fixed amount and eventually change and pay by the hour
(and add other perks) only later.

------
leelin
Cool, the post describes how to build a Nondeterministic Outsourcing machine
to solve your programmer problems... just fork a whole bunch of jobs trying to
solve the same problem and then pick the one that turns out best!

Sarcasm aside, I like the "I AM REAL" suggestion to auto-filter out the guys
who reply to every single job without reading. It works well on Craigslist
too, to reply with a special subject tag.

------
lukevdp
the best way to get a developer to work really hard on your project is find
one that has worked on similar projects and then pay them enough that they
don't have to have other jobs on the go.

The biggest reason for a developers work to slow is that they have another
job. Ask the developer if they've got other work on, when it's scheduled for.
If they are the type to have lots of projects on... Pass or ask that your job
be their only job for a specified time.

Hiring off shore for a complicated app is simply an exercise in banging your
head against the wall. You can give an identical spec to two programmers and
have a great app and a piece of crap come back. Hiring offshore is bad because
1. It's harder to communicat. With them due to them not being native English
speakers And 2. At least in some countries there's a culture of doing the
minimum required to get the job done.

Having said that, if you are non technical and have a limited budget, I think
the original article is a pretty good way to hire someone in a bad situation.

~~~
ericb
Could not agree more! Hiring someone who has already done something similar
and received a good review is as close to a guarantee that the project will
work out as you can get. I have done some

That said, once you've used them, I find it is ok to branch out a little and
stick with the same person.

Still, I generally stick to branching out _only a little_ because I find
giving a web app to the "Firefox Extension Guy" might mean you are out of
their sweet spot--they may not enjoy web app development which slows them
down, or they may not be very proficient at it.

------
lvecsey
I was listening to a project proposal the other day and had a similar set of
questions to guide the conversation. It was actually with a psychologist and I
think that field and way of thinking represents the exact flip side of the
type of rational thought that is reinforced and developed by programming. I'll
likely end up turning down the project; my biggest fear is getting sucked into
something that won't conclude well, so I'm going to use this fleshed out
guideline next week and see how many of the steps I can reach clarity on.

------
T_S_
There is an overwhelming desire by non-programming business people to reduce
programming to something they understand better. Not knowing how to program,
they have to grasp for analogies like building a house, a bridge or some other
large engineering product.

The problem with this is that every large development project I have seen on
included a large element of what is really R&D. Most of the engineering around
came in the from network admins, DBAs and sysadmins and, most of all,
compilers. To roll with the analogy, the development team was designing new
studs, beams, screws, and other widgets, to be produced by a (zero cost!)
digital factory and later installed by a team of helpers.

This perception gap leads to all sorts of dysfunctional behavior and game
playing on both sides. The example you see here is like working extremely hard
to boil down your R&D to the equivalent of a one day high school lab, and then
staging a contest. It will definitely give you some information, but won't
solve the original problem.

~~~
noverloop
I like to explain programming by comparing it to writing a book. You can't
change the plot-lines overnight without having to throw away a few chapters,
as well does the plot always have an impact on the story that builds up to it.
Starting to write a book without a good grasp of what story you want to write
will probably just be a time-suck.

Both are a produce of intellectual activity and require adequate understanding
of the goal in order to streamline the product.

------
kls
_Leave off all details that the programmer doesn't need to know._

I differ on this, what you need is a clear road map, not people left in the
dark. A feature for 2.0 may require a portion of 1.0 to be designed in a
certain way, if you omit the knowledge of that feature coming down the road,
you may be looking at a costly rewrite to adapt the app to that feature.
Whereas the developer having for knowledge of the feature may steer them in
designing the system with the though it mind that it will be coming.

 _you're paying multiple times for this first milestone, but it's worth it to
find a good one_

This is not good advice. You would be much better off combining that money and
hiring a proven senior level guy, as one senior level guy can outperform a
group of junior level guys. Which is what you get many times when you solicit
from those sites. To be honest those sites are a race to the bottom and no
senior level guys are lurking there because they have plenty of work and don't
need to compete in that race.

The best advice is to break your 1.0 requirements into micro-milestones with
the respective developer, the trick is to get them down to 40hr increments,
for example you ask the developer do you think you can get account create /
update done in 40hrs and the developer says yes with the exception of roles
and permissions, or just yes, I can get that all done.

You work the contract from that perspective, they have to produce something in
40hrs and if they start going over then it becomes apparent quickly and you
are rarely ever at risk of loosing more than 40hrs. This allows you to measure
your risk in small increments and allows you to cut loose at the point that
they start failing, while still having and completed 40hr blocks as feature
complete, that you can turn over to a new developer should they start failing.

For instance, say you have 3 features in 1.0: account, orders and inventory.
say the developer does account in 40hrs, submits it to you and it is feature
complete, you then move on to orders and the developer misses 40 and claims
that he needs 20hrs more (it happens) so you give him the 20hrs and it comes
back feature complete. Now you have 2/3 done, but at any given time you where
only at risk for a 40hr loss and 60hr loss when you decided to take a greater
risk. Finally, say they miss inventory and claim it will take them another
40hrs, you decide that you are willing to assume 80hrs risk and it still come
back defective and it will be yet another 40hrs. At this point you feel that
it is too much risk so you cancel the contract, you are still in possession of
2/3 of the development effort and you can solicit for that final 1/3. As well
you can opt at that point to diversify because you are loosing faith in the
original developer at which point you could agree to the addition 40hrs with
the original developer while hiring another developer to build the final 1/3
in parallel, in case the original developer is not able to complete the task.

One other thing to note, is when the first 40hrs is complete hire an
independent party to review the architecture and the code to ensure that it is
not a ball of spaghetti that will become a maintenance nightmare.

This is a far more pragmatic approach to hiring a developer.

~~~
cookiecaper
I've spent the last couple of weeks looking for work on Elance, things have
been pretty slow. There are some good people there (one of my old co-workers
introduced me to it), but it's easy to lose them in the mass of offshored
firms. It doesn't help that most people who post bids there only care about
the price and will go with the cheapest one, which is the offshored firms.

I got my foot in the door on one job by charging the minimum for it ($50)
because it involved changing one line of code (guy sent me the script for
review before I bid). I'm now revamping more of that for a little bit more.
But every other bid I've placed has been declined and they've accepted people
who must work for $15/hr or less.

Elance is a totally depressing place, but all of our clients have us on hold
so I'm looking everywhere I can.

~~~
kls
Thanks, your musing gave me a great idea for a site. I just registered the
domain name igi.gs (if only you could do 2 letter domain names gi.gs would
have been awesome). My idea is invitation only freelance site where members
have to invite new members and new members have to have a proven track record,
its real loose in my mind right now, but I think I am on to something, all the
other offerings in this area are a crap shoot. Maybe some form of bare minimum
rate as well so it does not become a race to the bottom.

~~~
phreanix
There are a couple of better domain names i can think of that that.

How would you populate initially?

~~~
kls
If you want to share them, I am all ears. I am working on how I would seed the
site now. My initial thought was to target reputable blogging freelancers and
make them the initial group. I was also thinking that maybe also allowing open
enrollment, but only allowing open enrollment individuals to bid for extremely
small projects (under $500, so if the minimum allowable rate is $50hr then
10hr projects) this would allow them to build rank slowly, as well if a member
uses them for services they can up them to an invited status. As well I have
formulated the idea that a member is forever linked to their invites. If you
invite someone to the site and they do good your recommendation rank goes up,
if they are bad your recommendation rank goes down. If it gets too low you are
no longer allowed to invite people, as it gets higher you are allowed to
invite more people. This has no bearing on your abilities rank (which is what
gets you gigs). My other thought is new members get feed smaller projects and
as their ability rank grows then they are feed larger projects. As well, I
think I would go with pure rank not a pure customer satisfaction indicator one
bad project can ruin an otherwise good freelancer on the site and lets face it
at some point for whatever reason, you are going to run into a bad project. I
think the site could make money by being a paid verification service where we
would charge a fee to certify that the code is of good quality and we act as
PM's to make sure the project is tracking to the schedule.

~~~
phreanix
email me, address is in my profile.

~~~
kls
it's not in your profile you have to put it in the about section if you want
other members to see it.

~~~
phreanix
Woops. Sorry, updated.

------
davidmathers
_“VERY IMPORTANT: To separate you from the spammers, please write I AM REAL as
the first line of your bid. We will delete all bids that do not start with
this phrase, since most bidders never read the requirements._

Van Halen:

Just as a little test, in the technical aspect of the rider, it would say
"Article 148: There will be fifteen amperage voltage sockets at twenty-foot
spaces, evenly, providing nineteen amperes..." This kind of thing. And article
number 126, in the middle of nowhere, was: "There will be no brown M&M's in
the backstage area, upon pain of forfeiture of the show, with full
compensation."

So, when I would walk backstage, if I saw a brown M&M in that bowl ... well,
line-check the entire production. Guaranteed you're going to arrive at a
technical error. They didn't read the contract. Guaranteed you'd run into a
problem. Sometimes it would threaten to just destroy the whole show. Something
like, literally, life-threatening.

The folks in Pueblo, Colorado, at the university, took the contract rather
kinda casual. I came backstage. I found some brown M&M's, I went into full
Shakespearean "WHAT is this before me?" ... you know, with the skull in one
hand ... and promptly trashed the dressing room. Dumped the buffet, kicked a
hole in the door, twelve thousand dollars' worth of fun.

The staging sank through their floor. They didn't bother to look at the weight
requirements or anything, and this sank through their new flooring and did
eighty thousand dollars' worth of damage to the arena floor. The whole thing
had to be replaced. It came out in the press that I discovered brown M&M's and
did eighty-five thousand dollars' worth of damage to the backstage area.

Well, who am I to get in the way of a good rumor?

<http://www.snopes.com/music/artists/vanhalen.asp>

[http://www.thesmokinggun.com/archive/years/2008/1211081vanha...](http://www.thesmokinggun.com/archive/years/2008/1211081vanhalen1.html)

------
midnightmonster
Most freelancers seem to be concerned about being out of the loop if people
followed this advice. I can feel that, too: IMO clients almost always benefit
from the improvements I make to whatever they were planning.

But what I really wonder is how many people even could follow this advice. In
the years I've been freelancing I don't think I've ever received even a single
feature request that was thought out to the every click, every branch level of
detail--let alone an entire application.

------
alttab
I stopped reading at describe every click. This guy is our worst nightmare who
has worked with too many talentless hacks.

------
rmundo
How about using this idea to hire people long term for your company, as a
supplement to the interview? Filter through resumes, send promising ones a one
day scope problem, with a one day deadline and one day's pay. Allow one or two
"call tickets" where they can contact you for feedback.

------
siglesias
This comment applies to non-engineer college students who have ideas for
complex websites, big ambitions, and are looking for programming help. This
doesn't apply to those looking for spot jobs and minor features.

Personally, I've gotten burned big time hiring "talent" abroad, even utilizing
a bidding and feedback system like that on getafreelancer.com, primarily due
to the fact that (at least for me), it's impossible to get a foreigner psyched
on a predominately American consumer product. I found that these programmers
are constantly striving to provide the bare minimum, they constantly recycle
code from other projects where they think it might fit (even if it doesn't),
and they are desperate to close the ticket on your project and move on to the
next as quickly as possible.

In my opinion, my observations fall in very closely with what Marx describes
as "alienation," wherein workers (or in this case, foreign programmers) are to
the extreme out of touch with what they are making. Sure, you can provide
detailed documents specifying the exact nuances of what you want implemented,
but you will NEVER anticipate the misunderstandings that are possible when
traversing across complex language barriers, and secondly, you will never get
the fit, finish, and craftsmanship that only somebody passionate about the
product can imbue into it.

The second trap, of course, is to think that you can hire American
freelancers, or, better yet, the "hacker" at your particular university. This,
of course, comes with other disadvantages. It is often the case that
university undergraduate "hackers" have several pet projects, and even in the
case that they are open to discussing programming your idea, they often
eventually begin to doubt whether it is worth it to essentially build your
website for you (as they see it) as you sit around and tell them what to do.
After all, did YOU spend the time, sweat, and endure social ostracism honing
the valuable skill of computer programming as they did for years? Look no
further than what happened to the Winklevoss twins at Harvard when they tried
to get Zuckerberg to do ConnectU.

These arrangements almost inevitable fall through, consistently. Having been
very close to entrepreneurship circles at an elite university, I can tell you
that I have never once seen a non-hacker recruit a hacker to build a product
successfully, though I've seen, and made, multiple attempts. The hacker's pet
project ALWAYS comes first, followed by school and internships. And too many
hackers, in my observation, are trying to chase the Zuckerberg dream by
precluding any strong non-coding liberal arts thinkers from their teams and
making all business and user experience decisions themselves. I can't speak to
the success of this trend because I haven't seen the opposite case even
attempted due to the pervasiveness of this hacker-centric startup attitude.

My pessimistic conclusion (though it might have a silver lining) is that
unless you have a really trusting programmer friend who will help you out of
your preexisting relationship, it is both not worth it to pursue hiring a
programmer for your startup from abroad and not worth it to pursue alliances
with your local college hacker. The best way to go is to bite the bullet and
learn to code, and that way you actually have a means of effectuating your own
ideas, which are liable to change, multiply, grow, etc. at a pace that you
will want to control. Once you learn to code, you'll gain more respect of the
hacker types anyway, and from that point you can build meaningful alliances of
mutual understanding and respect. This is the route that I have taken, and I
don't regret it one iota. A year into programming, I've got three iPhone
applications in the store, with several more coming. The only limit for me,
now, is time, and that's the only limit you really ever want to confront when
building a startup. Depending on a stranger who is just doing it for money?
For the birds.

