
How do you recognise good programmers if you’re a business guy? - known
http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/
======
ryanwaggoner
I love HN and the crowd here. It's by far the absolute best online community
I've ever been a part of.

That being said, the arrogance displayed in many of the comments on this
thread and others like it is one of the things I dislike most here. There's
this pervasive attitude that hackers > businesspeople, and while it's
ridiculous for a business guy to think he can hire a programmer (or be of much
value to one), you never see articles about how hackers are helpless without
business people or how a hacker would have no idea how to hire a marketing or
sales guy (and shouldn't even try).

Maybe I'm overreacting because I'm one of those who straddle the line, but
this kind of arrogance serves no one.

~~~
swombat
Worth pointing out that the article proposes the opposite: that business guys
_can_ learn how to hire hackers, thanks to that list of indicators I pulled
together.

~~~
ryanwaggoner
Agreed, and my comment wasn't aimed at the article so much as the comments
here about the article.

~~~
swombat
Couldn't agree more, then.

------
plinkplonk
The blogger explicitly quotes PG as saying

"In practice what happens is that the business guys choose people they think
are good programmers (it says here on his resume that he’s a Microsoft
Certified Developer) but who aren’t. Then they’re mystified to find that their
startup lumbers along like a World War II bomber while their competitors
scream past like jet fighters. This kind of startup is in the same position as
a big company, but without the advantages.

So how do you pick good programmers if you’re not a programmer? I don’t think
there’s an answer. I was about to say you’d have to find a good programmer to
help you hire people. But if you can’t recognize good programmers, how would
you even do that?”

And then goes on to say he disagrees with PG and then provides some
"indicators" that business guys can use to guide their search .

The thing is, a "business guy" is in no shape to judge any of these
"indicators" accurately even if we grant that these are valid (which I don't).

. How would this hypothetical business guy recognize "passion for programming"
(one of the "indicators" for recognizing programming excellence the author
mentions)?

Let us see what he says

"Good programmers will have a tendency to talk your ear off about some
technical detail of what they’re working on (but while clearly believing,
sincerely, that what they’re talking about is really worth talking about).
Some people might see that as maladapted social skills (which it is), but if
you want to recognise a good developer, this passion for what they’re doing at
the expense of social smoothness is a very strong indicator. Can you get this
guy to excitedly chat up a technology that he’s using, for a whole half hour,
without losing steam? Then you might be onto a winner."

Yeah right!!! This reminds me of some managers I know who'd make these kinds
of judgments and reward the most technically inept members of the team because
they "excitedly talk your ears off". Most of the talk would be technically
incoherent but how would they know? all they detect is the "passion".

The rest of the "indicators" are similarly flawed.

PS the comments are hilarious too. I particularly liked "The above list is
excellent (and it describes me perfectly). " :-D

~~~
swombat
None of those indicators were meant to be taken in isolation. Each of them, by
itself, means nothing.

Taken altogether, they are helpful because they allow someone with little
technical expertise to at least have a snowflake's chance in hell of
recognising programing talent. If someone is enthusiastic, has a broad
technical skill set, has been programming since before uni, loves to talk
about the latest bit of technology he's picked up, is articulate, smart,
learns technical stuff by himself, and has a tendency to work on side projects
(rather than having all his experience on the CV), then they're far more
likely to be a good programmer than not.

Remember, a business guy is effectively flying blind. I can sit with someone
for 15 minutes and tell you whether they're a good hacker or not without
having asked a single technical question, but someone with no technical skills
cannot do that - nor can they figure out how to recognise someone like me to
ask me to do it for them. They'll get fooled by certification-laden "software
architects" who haven't written a line of code in years and will happily help
them hire a football team's worth of mediocre programming talent.

I put together this list over a year ago to help non-technical people in this
situation, and others must have found it useful, since over time it's accrued
some 300'000 visitors and been linked to from pretty much everywhere.

If you feel you can come up with a better list of indicators, please do so,
I'll be the first to vote you up.

~~~
Retric
You are trying to measure how hot a fire is by how much smoke it's producing.
While on average smoke and fire are related it's not a great indicator. A
simple solution would be to get 10 programmers into the same room and talk
about a technical problem and ask them to privatly evalutate eachother
afterward. But, that's not "fast" and "cheep" so most people go for guessing
games.

~~~
trevelyan
My worst hire was a java guy that I took a gamble on because we were short
staff and could have used some help with mobile stuff. He was fired within two
weeks, so I totally understand where this guy is coming from. I've also done
interviews where I've asked candidates why they became interested in
programming and they replied, "I don't really like computers, I just do this
for the money." One guy actually said exactly that.

When 95% of the people you see coming through the door are like this I could
see a non-programmer not being in a position to figure out that these people
simply aren't worth hiring.... the solution I don't see addressed is more
rapid and iterative trial and error in the development hiring process:
bringing people on in a limited capacity or throwing them at smaller and
contained technical projects before giving them responsibility for more
important stuff. I'm a big fan of finding good people for part-time work and
then growing them into full time positions if the business model starts
supporting it and they want more work. This has worked well for non-
programming stuff too.

~~~
mannicken
I don't 'just do this for money' but an employer that explicitly requires
passion and 'not doing it for money' looks like trying to get off paying less
and have me working for 'the big idea'.

------
swombat
I think this is the third time this article of mine gets up to the top of HN.
The first time was when it was slashdotted and that's when I found out about
HN. Second time was this past summer.

Maybe I should write an updated version of it...

On the other hand, I'd like to add a disclaimer for those reading this article
for the first time:

I wrote this a year and a half ago. My ideas on the topic are clearer and can
probably be better explained now. So it's worth considering that when you say
"this blogger believes blah blah blah", "this blogger" does not exist anymore.
I've moved on and if I write this article again (which I may well do), I'll be
sure to make it far more convincing than I was able to 18 months ago.

Btw: My new blog, which you've probably seen recently, is
<http://danieltenner.com> . If I post an updated version of this article, it
will appear on my new blog, not on inter-sections.

~~~
radu_floricica
Well, if you have any insights into hiring for non-programming positions, it
would be welcome in the next version. On HN it's probably more needed then the
original article.

------
DarkShikari
The answer is obvious: the businesspeople should learn to hack.

My boss is a pure business guy. He didn't rise up from the ranks to become the
boss; he's run multiple startups, and each time he's served as a "business
guy," not a hacker.

Yet despite this he knows enough about every facet of his business that you
can explain to him a subtle bug in our software or an algorithm involving
frequency transforms--and he'll _understand you_. The power of this is
incredible; while it takes a good amount of effort to be familiar with the
technical aspects of the business, it gives so many benefits--from the obvious
(the hackers trust you more and are more likely to give you the accurate
lowdown on any situation or proposal) to the less obvious (you can recognize
good hackers better).

Recently, he wrote a very complex threading patch that dealt with all sorts of
race conditions for a program that, while part of our business, _he had never
touched before._

Being a "business type" does not justify being clueless about the technical
aspects of your business.

~~~
moe
_Recently, he wrote a very complex threading patch that dealt with all sorts
of race conditions for a program that, while part of our business, he had
never touched before._

Sorry, but that kind of super-hero is a very, very rare breed. When did he
learn about multithreaded programming? You don't just pick that up along the
way anyhow.

Honestly your story sounds more like a Hacker who turned business-guy a while
ago than a business-guy who magically accumulated hacker skills.

~~~
strlen
> Sorry, but that kind of super-hero is a very, very rare breed.

First start-up success is very rare as well, so perhaps it _should_ follow
that it involves a rare breed of people.

As for multi-threaded programming-- that is one skill that universities
generally teach well as a part of undergraduate computer science programs
(although I can only speak for mine). It's also generally about recognizing
patterns (consumer/producer problem, dining philosopher problems) and being
able to see them irrespective of the implementation (I first began playing
with POSIX threads before college, learned the formal concepts in a class
which used Solaris threads and am now working through Doug Lea's book about
concurrency in Java: <http://java.sun.com/docs/books/cp/>).

There are many people who go into MBA and JD programs with CS and EE
undergraduate degrees (it's excellent preparation in the sense that it's a lot
of brain gymnastic; statistics also show many undergraduate engineer majors
also go on to medical school as well). So one may not necessarily be a hacker
(they don't code for fun) but have a CS education -- or they may even be a
hacker (they _do_ code for fun) without being a professional developer
(they've never worked in a software engineering organization).

Incidentally, I can describe people that fit _all_ of those molds (many CEOs
of big companies generally fit the "has a technical undergraduate background,
climbed the technical ladder at big-co, got an MBA and switched to management
or sales" pattern; start-up founders frequently fit the "worked on Wall-Street
by day, coded for fun by night" pattern).

~~~
DarkShikari
_First start-up success is very rare as well, so perhaps it should follow that
it involves a rare breed of people._

I didn't say all his startups were successful ;)

His third (I think) startup, the current one, is quite successful though, and
he hopes to be able to sell it for at least a billion eventually. Current
estimated valuation is a quarter of a billion with at least 50m in VC (don't
know the exact numbers). About ~60 employees.

On the topic of the GP post: you talk about a "businessperson who magically
acquired hacker skills"--but is it somehow more likely to have a "hacker who
magically acquires businessperson skills"?

~~~
donaq
Yes, I do think it is more likely, because "businessperson skills" are skills
that an observant and intelligent person might pick up in the normal course of
his life, for example, arithmetic.

 _I think business is very simple. Profit. Loss. Take the sales, subtract the
costs, you get this big positive number. The math is quite straightforward. -
Bill Gates_

Then there's negotiation/persuasion/deal-making/people skills. Most people
engage in activities involving variations of those everyday. You'd almost have
to be a hermit to _avoid_ picking up _some_ people skills. While some hackers
may halfway fit that description, I doubt that most do.

Acquiring hacker skills, OTOH, involves rather more specialized effort.

------
ryanwaggoner
This isn't rocket science, and programmers aren't special. Programming is a
deep technical skill, just like many others, and the way you hire for those
types of positions if you don't understand them is to rely on the judgment of
others who do. These people helping you evaluate technical candidates don't
have to be employees, by the way. They could be, but they could also be your
friends, family members, advisors, colleagues from a former job, etc., etc.
Just calling a programmers past employers and managers is a good start.

You can also intuit something about someone's technical skills by looking at
the types of places they've worked for. Some guy who has hacked together fifty
is likely not as technically skilled as someone who worked at Google and
Facebook. That's not a full-proof test, obviously, but there isn't a full-
proof test here, even if you are a programmer.

~~~
plinkplonk
"This isn't rocket science, and programmers aren't special. "

I agree completely.

" Programming is a deep technical skill, just like many others, and the way
you hire for those types of positions if you don't understand them is to rely
on the judgment of others who do."

Exactly! This is the central point. This is how I (as a programmer) would find
a good lawyer or doctor or helicopter pilot from large numbes of doctors or
lawyers or pilots with similair sounding degrees and other "indicators", for
example.

I am just not convinced of the whole idea of using "indicators" as a
substitute for the above. It is not so much that any indicators are wrong in
themselves , but that unless I have someone who knows how to use those
indicators correctly.

Now I don't know anyone who can help me with the judging , I could go with a
list of "common sense" indicators and take my chances. I have serious doubts
on how much this will succeed in picking an exceptional doctor/lawyer/pilot
etc.

------
spaghetti
Three things come to mind (explanations follow):

1) Does the programmer _complete_ interesting programming projects in their
spare time?

2) Can the programmer explain something mildly technical such that you, the
business guy, can understand?

3) A test: push the programmer a bit. Act as if you don't understand something
and be a bit rude. If the programmer does anything except listen to you and
patiently try to help you then he/she is no-hire.

Explanations:

If the programmer doesn't complete interesting projects in their spare time
they don't have enough passion for programming.

If he/she can't explain something clearly it's highly likely they can't
communicate with business folks effectively in general hence they're not going
to be effective at the job.

There's a lot of angry programmers. If the programmer becomes visibly annoyed
or angry during an interview you've found yourself a no-hire. Angry
programmers destroy morale very quickly.

That's my opinion on how to find "good" programmers. Keep in mind the
percentage of "good" programmers who will be a good fit for your business is
small. This is where respectful drilling of technical matters is appropriate.
This part of the interview is completed by a _technical_ employee. Remember
that lots of good programmers can fail technical interviews because they just
don't know the particular technology.

~~~
ilaksh
1) I have completed some. I have started many more than I completed. More of
my energy goes into making sure I complete projects I am actually getting
payed for. Also, I could say that it was complete any time I wanted, but what
fun would that be?

2) Good point.

3) If someone pushes me rudely then I am going to get mad at them and they
will know it because I am human and I have every right to get angry. I don't
like to put up a front. This is why I'm a programmer and not a salesperson,
executive, or someone who's job it is to be two-faced. Does that mean I won't
continue to try to help a rude person that genuinely needs help and that is
not just trying to manipulate me? No, but that's a different situation.

4) If they become angry or annoyed because you were deliberately rude like you
suggested above, then it doesn't make sense to eliminate them for that reason.
If you were polite and human and ordinary conversation angered them, then that
is a red flag that no one needs you to point out.

5) I have a feeling if I interviewed with you for more than thirty seconds I
would come off as another one of your angry programmers, because I would be at
that point.

6) Respectful drilling of technical matters: i.e. programming languages and
API pop-quizzes? "Respectful" drilling? What does a verbal pop-quiz have to do
with programming? What about this part: do your existing programmers and
managers like the person?

What is your name so I can avoid ever working for you?

------
jibiki
I am certainly not a good programmer, and using this logic, you might hire me.
So your list isn't perfect; however, I suspect that it's pretty good. The
basic problem is that it won't distinguish between people who are really
enthusiastic about computers and genuine good programmers. The difference
between these two groups is probably really obvious in a field like chess
(lots of people who are enthusiastic about chess are still terrible,) but it
might be harder to notice in a knowledge-based field like programming.

~~~
swombat
That's a very good point, but you're forgetting about the "hidden projects"
indicator. That should help prove that the "candidate" is not only
enthusiastic, but also capable. Someone who has a bunch of open source
projects going is likely to be able to deliver as well as talk the talk.

------
radu_floricica
I've been both on the programming and business side, and done a little hiring.
Pretty much the only indicator I can always apply is projects done outside of
paid work.

I start with the usual "reverse a linked list" stuff or easier, go through
education and work experience, play the whole game, but the thing that really
does it for me is that he learns erlang in his free time, or has a self-made
javascript game on his home page (if he's a web developer) or whatever. It
only has to be completely non-paid non-contracted work. Then of course I look
at the source code, but the decision is already half made.

There is a much longer list of things that disqualify a candidate. Anything
Entreprise, any formal certifications outside college, personality (yes, I
discriminate. I like working with people I like working with, apparently). But
a checklist for a good programmer, I doubt it can be applied successfully.

edit: * entreprise = using oracle for mom&pop shops, not working in big
companies. Sounds obvious, but it's sadly too common mindset to use the most
expensive/complicated solution instead of the cheapes/simplest, to the point
that just hearing "entreprise" turns me off.

------
modoc
If you know a good technical person you trust, ask them to help. If you don't,
go make some technical friends.

I've been helping screen technical people for friend's companies for a while
now. My friends trust me to determine if someone is the right fit for the
role, technically. I'm too busy on my own projects to work for/with my friends
full time, but I can spend an hour or two doing phone screens, interviews,
reading resumes, etc... Some of them even pay me for it:)

There's no magic formula that lets you (a business guy) figure out who's
great, who's really green, who's full of crap, etc... It can't be done. You
have to rely on a web of trust, using your friends.

~~~
swombat
Obviously, that's the ideal. But how would they recognise you in the first
place, to know to ask _you_ to do their technical hiring?

------
kellishaver
The bit about a good programmer knowing a lot of unrelated technologies is
entirely off-base, IMO. Better to specialize in one area and be the best you
can be at that than spend your time learning a lot of technologies you will
never use, just for the sake of knowing them. I do think knowing more than one
language is a definite plus, but keeping them all related makes perfect sense
(a web stack, a java stack, etc.).Even great programmers who are infinitely
passionate about what they do aren't going to enjoy every programming language
out there, just by virtue of it being a programming language.

------
sharjeel
There's one test I recommend to my semi-technical fellows:

Give a small practical problem to solve and see what the other person comes up
with. For instance you could ask prospective employee to hack together a small
app or a script to do something or anything you can understand and think is
solvable with technology.

The great part of this test is that most of the time slackers just don't even
attempt it. For those who give a shot, you can look at certain behavioral
patterns using your softskills. For a non-techie judge, you won't be able to
analyze the quality of design but the end result also says a lot.

------
replicatorblog
I think the list is helpful and the comments suggesting that non-technical
folks have no chance to hire good hackers seems to be contradicted by facts.
FedEx and Walmart have amazing technical systems and have become industry
leaders because of them, but both were founded and grown by business folks.
Disney, Bank of America, and most of the other Fortune 500 have retained their
positions by building strong technical organizations largely from scratch.
Good sales people, ops folks, and hackers are always going to be hard to find.

------
richcollins
This is like a football coach asking how to recognize good players. If you are
asking, you probably shouldn't be working on something where programming is
central to your success.

------
critic
It's pretty hard (even if you are a great programmer). If you are looking to
find a great programmer who's available long-term, hire someone who's PROVABLY
great and available short-term to do the interviews/search for you. Think
Stroustrup or Stepanov if you are looking for C++ programmers. RMS or Steele
if you are looking for Lisp programmers, etc.

For every good programmer I know, I know many more who are total bozos who
claim to be great and are thought by some to be great.

------
bokonist
The obvious answer is to hold a bake off. Narrow down the programmers to a set
you want to try out (for this you can use rough measures - SAT scores and
experience listed on resume). Give them all a few days to implement a non-
trivial part of the app you want built. Then hire the best.

~~~
ms01
Why not just give them different parts. The last guy you interview you give
the task of putting together the different pieces, and then you have your
finished application. Of course you should also interview QA people so they
can find the problems with what they other guys did...

~~~
tvon
Assuming you're not joking...

Aside from that just being a very dishonest way to conduct business, you'd
spend all your time organizing people who are working together who don't know
they are working together. Even if you could manage that, you'd have no way of
assembling the finished components into a working application, and there is
just no way you could find someone capable of handling that task that was also
foolish enough to think such a complex operation would be part of a job
screening process conducted by a person incapable of knowing if it's done well
or not. In fact, it's very unlikely you'd fool any experienced developers
they'd quickly deduce that you don't know enough about the code to judge it's
quality.

The end result would be a pile of code that wouldn't work and you'd have no
way of fixing it without hiring an even more exceptional programmer, who would
probably tell you to throw out 90% of the work and start over.

------
rsheridan6
This is better than just hiring an MCSE, but, having dabbled in open source
software, I've seen a lot of WTF-worthy code written by people who would
fulfill all of those criteria (well, I couldn't honestly say whether you could
hold a conversation with them).

Is there any such thing as a headhunter who is also a hacker? That would
probably be the best solution for the MBA-types, short of taking a few years
to learn to hack themselves.

------
JBiserkov
You don't. You can't. As PG wrote in "Great Hackers":

I've seen occasional articles about how to manage programmers. Really there
should be two articles: one about what to do if you are yourself a programmer,
and one about what to do if you're not. And the second could probably be
condensed into two words: give up.

~~~
kingkongrevenge
> You don't. You can't.

I call bullshit. There are many, many examples of successful technical teams
organized by people without deep relevant technical expertise.

All this PHB stereotyping around here is just arrogant vanity.

~~~
anamax
> I call bullshit.

WTF. Is this some sort of playground?

> There are many, many examples of successful technical teams organized by
> people without deep relevant technical expertise.

And there are many many more that are complete disasters. As they say, a blind
pig occasionally finds an acorn.

> All this PHB stereotyping around here is just arrogant vanity.

Actually, it's experience.

The interesting difference is that technical folk don't claim any particular
skill in the domain of PHBs but the PHBs claim incredible skill in technical
domains.

If both are correct, there's something interesting going on, but let's see
some evidence.

~~~
teej
>> I call bullshit.

> WTF. Is this some sort of playground?

Calling people out is an important part of a healthy, critical discussion
focused on the exchange of ideas. I might not share someone's opionion, but I
aplaud fighting against groupthink.

>> All this PHB stereotyping around here is just arrogant vanity.

> Actually, it's experience.

Both sides of this discussion have pointed to ethereal "examples",
"experience" without giving any meat. Show the evidence - empirical or
anecdotal - to support your opinion.

> Let's see some evidence.

Let's see some evidence from your side too.

~~~
anamax
>>> I call bullshit.

>> WTF. Is this some sort of playground?

>Calling people out ,

Now you're escalating to a physical challenge. Like I said, playground.

> is an important part of a healthy, critical discussion

Actually, it isn't. In fact, calling someone out is one of the best indicators
that "healty, critical discussion" isn't anywhere near.

>>> All this PHB stereotyping around here is just arrogant vanity.

>> Actually, it's experience.

>Show the evidence - empirical or anecdotal - to support your opinion.

If you haven't read the other posts, citing them won't make any difference. If
you have and still think that there's no evidence, citing them won't make any
difference.

>> Let's see some evidence.

>Let's see some evidence from your side too.

For what? I wrote that technical people don't believe that they're good at
evaluating biz people. Which part of that is under dispute?

You seem to believe that biz people are good at evaluating technical people.
The sole piece of evidence is that there are successful teams "led" by biz
people, but that doesn't imply that said biz people evaluated the technical
people.

~~~
replicatorblog
This idea that there is no history of business types starting technical
businesses seems so silly. It is well beyond the "blind squirrel finding a
nut". A great manager can assemble a great team and the world of successful
companies show that.

EA - Trip Hawkins was a business guy, but somehow they dominate software.

eHarmony - A good sized web based business with a doc at the helm.

McDonalds - Everytime you order a big mac anywhere in the world a bun, patty,
slice of cheese, two pickles and a squirt of ketchup come out of inventory.

All of the airlines - May not lead to great business results, but they
certainly know software.

And of course these from my earlier comment:

Walmart

FedEx

Disney

Bank of America

For all the people who think it is impossible for non-hackers to hire a
hacker, why don't you comb through the Fortune 500 and prove your point, or
write a program to do so.

~~~
anamax
> This idea that there is no history of business types starting technical
> businesses seems so silly.

What's silly is the strawmen that are being thrown around. No one is arguing
that biz types can't start/lead tech biz.

The claim is that the vast majority of non-tech people can't usefully evaluate
tech people in time to do any good.

It's not unlike the complementary situation, technical people evaluating non-
technical people.

As I pointed out, if tech people can't evaluate non-tech and non-tech can
evaluate tech, something interesting is going on.

But, let's ask the question - do non-tech people think that tech people can
evaluate non-tech people? If so, why do tech people think otherwise? If not,
but non-tech can evaluate tech people, why the difference?

> EA - Trip Hawkins was a business guy, but somehow they dominate software.

Hawkins also always has a tech partner.

The same can be said for every other company on the list.

------
trapper
If I weren't technical I would go to a local university. I would contract
someone who is well published in something with a combination of math and
computer science to screen my hires for people he would consider for his lab,
and assume that from there I could tell the difference.

~~~
critic
I suspect that math is hard for bozos, but I actually know tenured CS
professors who are total bozos at programming, and probably shouldn't be
listened to even regarding minor issues. Publishing fluff papers, going to
conferences, writing grant proposals and politicking is all they are good for.

~~~
trapper
Exactly. That's why I suggested math/cosc combos.

------
grandalf
This will probably not make it above the noise in the thread but I think the
following would be useful:

\- You would ideally have at least one person who you trust who is a coder who
you can show source code samples, previous work, etc., for a quality
assessment.

\- Previous business references are valuable, as only so much of the overall
usefulness of the person comes from raw coding ability -- there may be other
habits, personality characteristics, etc., that (good or bad) might influence
the decision.

\- I highly recommend starting out a new coder with a simple contract project
so that you can assess her ability to communicate, work toward a goal, etc.
You should probably pay whatever the coder thinks is fair, b/c this is not a
bidding war exercise. You mainly want to see about work habits, style,
compatibility with the existing team, productivity, etc. By doing this you are
giving both parties (yourself and the programmer) a chance to feel each other
out and determine if it's a good fit. This can even be done as a part-time
project while the programmer is still employed elsewhere, reducing risk for
everyone involved.

\- Things like blogs, open source contributions, etc., are nice, but I think
of them as a hobby and unless you're thinking of hiring one of the few very
well known luminaries in a software community, the fact that your prospective
hire has a blog is probably not all that indicative of superstar qualities.

\- Character traits like tinkering are great too, but just because someone is
focused on a main task and doesn't tinker with each new thing that comes along
doesn't mean she's somehow a worse programmer than the tinkerer who writes
something in every new framework, etc. I have known great coders with both
characteristics and I think the bottom line is that good coders know what's
out there and can easily help you evaluate it for your business, even if they
didn't spend the past 5 weekends hacking out a side project in erlang --
unless of course you truly end up wanting to use erlang, at which point their
side project was a great investment that cost you nothing. However, most
skilled coders could read up on erlang and catch up in about a week, so we're
not talking about all that much overall productivity.

\- I'd beware of coders who prefer highly complex solutions to problems -- in
a business scenario sometimes a less elegant, easily understood solution is
ideal.

\- I'd beware of coders who are unwilling to adapt to your demand for quality.
Perhaps you don't need 3000 lines of test code for an internal whiteboard app.
It's good to find a coder you can trust to make the right call, but some are
very unconcerned with your budget and timeline and may not realize where the
rubber meets the road from a business perspective.

Any hire is going to be a relationship and hiring a coder is not too different
from hiring a business person. You need to establish trust and confidence.
Frank and clear communication is key to this. The coder should not think of
you as a "suit" and you should not think of her as a geek. Ultimately the
reason anyone is getting paid is because it's a business and that requires
judicious use of tradeoffs.

------
chiffonade
> How do you recognise good programmers if you’re a business guy?

Simple. Ask someone who knows. If you don't know anyone who knows, you might
want to reevaluate whether you should be getting into the tech industry.

As for the arrogance thing - look at Brin/Page, Ellison and Gates, etc. - all
hackers. When a "business" guy's achievements in the hacker space outdo these
hackers' achievements in the business world, be sure to let me know.

~~~
medianama
I'd surely want to hear about your achievements though

~~~
maxharris
Your comment is a simple ad hominem attack - it barely ranks DH1 (just one
step above name-calling.)

<http://www.paulgraham.com/disagree.html>

As your mother should have told you, if you don't have a substantive argument
to make, don't try to make one at all.

