Hacker News new | past | comments | ask | show | jobs | submit login

I subscribe to the Build Stuff school of programmer evaluation. Why do you hire a programmer? So you can have him build stuff. Has he built stuff? Then he can probably build stuff. If he hasn't build stuff, he might be able to build stuff, but it is a better idea to have somebody else pay to figure out whether he can build stuff or not.



I think this perspective is overly simplistic. But then you might have meant it that way, so the rest of us can fill it in with our sundry biases. So, here's my chance to make my biases obvious. :-)

Hiring a programmer who has built stuff is like hiring a contractor who has shown an ability to do carpentry work. It's swell when all you need is the carpenter equivalent of a programmer; but often there is more involved than just nailing lines of code, classes and modules together from someone else's specification.

So, having a criterion of having built stuff is not sufficient, although I think it is reasonable. What qualifies as "stuff" is pretty subjective, though, and probably can't be anything but subjective. As I mentioned above: biases abound.

You also need to make sure they are able to figure out what to build and how, and sometimes what not to build -- whether that means they buy it, or it is a superfluous component.

You need to make sure they can think about what they are doing, rather than just being able to do things. The couple of outside projects I've become involved in so far, and some of the code I've read for other projects I'm not actively working on, suggest that some people don't do enough thinking. They've built plenty, but they didn't appear to build it with any goal but to build version 1 and be done. Think the software equivalent of a contractor coming in to fix what the first carpenter screwed up, because the first carpenter didn't care once the house passed inspection.

The code I've dealt with inside of organizations I've worked for is, if anything, worse than the code outside. But just looking at the end product wouldn't indicate anything is particularly wrong, excepting that maybe improvements to the site tend to occur only once every geologic era. Sometimes this can be indicative of quality of the developers; sometimes it is indicative of the quality of the management. Either way, it may not reflect on the developer you are talking to.

Depending, the developer may be able to think at many levels, and might be able to think lucidly about their work from a business strategy perspective. And depending on the organizational culture, this can either be a wonderful thing, or the most undesirable thing imaginable.

But this is all based on some amount of personal bias based on the kind of work I would want to be doing. I know there are places where programmers are expected to be nothing more than carpenters given specifications by the system analysts to turn into code. In these cases, I can see showing just an aptitude for building things to be enough. But I don't think these cases are common enough to warrant a single best practice.


I subscribe to the Spolsky school of hiring: you need someone who's smart and gets things done. After all, any idiot can put together a neat website given a copy of "Learn Django in 21 Days". But is that person going to be able to move that site very far? Will they be able to understand other people's code?

Now, I'm not sure I agree with the author's point of any business person being able to spot a good programmer. But I think that if such a thing were possible, this would probably be how such a list would look.

But then again, we probably don't even agree on what a good programmer is. If there were an objective, standard way to find good programmers, articles like this wouldn't be necessary.


So, if everyone follows your philosophy, how do people get started building stuff?


Hint: You do not have to be employed by a company in order to build stuff.


When I say "if everyone follows this philosophy," I include both VCs and college acceptance boards in that antecedent. Then, presuming you don't have a trust fund, the only way to get your start building stuff is to do it on the side while being underemployed; this is a net efficiency loss for the economy.


Firstly, colleges are not in the business of making admittance decisions based on whether you are a good programmer or not; secondly, 40 hours a week is the standard for being reasonably well-employed, which leaves a whole lot of hours for doing your own thing in life (not to mention the years you're in primary and secondary school, during which many programmers build a pretty passable CV of personal work.)

I feel guilty even typing this much, because I don't think you're being intellectually honest at all. The vast array of open-source and free projects in the world speaks plainly about the ability of people to build useful things outside of work.


Okay, let me now be completely clear on how I interpreted your original statement:

Let "an institution" be "a place where one may work on projects safe in the knowledge that one's base needs for food and shelter will be met."

    I(x) := x is an institution

    S(x) := x seeks to join an institution

    A(x,y) := x will accept y

    P(x) := x has completed a project

    1. ∀xy( (S(x) ∧ I(y) ∧ A(y,x)) → P(x) )

    2. ∀xy∃z( (S(x) ∧ I(y) ∧ P(x)) → (I(z) ∧ y≠z ∧ A(z,x))) )

    ∴ ∀xy∃z( (S(x) ∧ I(y) ∧ A(y,x)) → (I(z) ∧ y≠z ∧ A(z,x))) )
Or more prosaically, "every institution that will accept a person (and thereby let them create a project) requires that there exists a project they have already completed (and thereby another institution willing to accept that person.)" Obviously there's a problem with that statement :)

That being said, I agree completely with your first paragraph. I was being half-satirical—not intending to find a flaw in your argument, so much as desiring to provoke you into strengthening your point by clarifying it (and trying to go one step beyond the common-sense assumption of "our current society" to see where this philosophy would take you.)

Do you think the world would be better if programmers could not transition into the workforce until they had created something that no one had asked them to create? The idea behind a company hiring you is that they need what you have, and so they pay you for it. If you're creating something and no one's paying you for it, then, presumably, either you aren't marketing it well enough, or it's something nobody needs (or you've made it as an act of goodwill, but the likelihood of Joe the Programmer writing FOSS as anything other than a prerequisite to a job—which, therefore, means that he really would rather have been paid, but just couldn't find a taker, again implying that he was underemployed—is slim to nil.)


I admit that I smiled when I saw a big response to me with chunks of predicate logic in it.

Do you think the world would be better if programmers could not transition into the workforce until they had created something that no one had asked them to create?

I'm not sure if the world would be better. There's an overwhelming demand for competent programmers, and not anywhere close to enough supply to fill it. Is it better to lower our standards, resulting in shoddy and sometimes dangerously bad work, or to leave things undone?

However, for any given single institution, I am very confident that that institution would be better off hiring only people who had created things which nobody asked them to create. I agree that these are usually things which either nobody needs, or which are marketed poorly; but I don't see why that would indicate anything negative about the person in question (as far as the company is concerned.)


I think this is trickier than just saying "do this, you obviously have time", but not for the reasons that derefr gave. I think you are assuming things that may not be true of all people, and then using that to draw very broad strokes which may have a steep rate of false predictions.

Forty hours a week is an theoretical standard; it says little about the actual hours put in by programmers. Urban lore suggests the accurate number is higher, sometimes much higher.

The free time a programmer isn't guaranteed to be available in large chunks for hacking. There are a number of things that can take up that time; some of them are bogus, but some are quite reasonable. Enough of that time gets chewed up, the programmer really doesn't have the kind of time they need to focus on deep, substantial projects. Some do find the time, but there are more factors involved than simply motivation.

As for primary and secondary school years, this too depends on a number of factors, not all of them matters of personal motivation and ability.

Assessment is hard enough when you don't have preconceived notions of the molds other people fit into; if you start assessing people already cherry-picking assumptions about them based on what societal fashion suggests is "normal," then your ability to fairly assess them is already screwed. You're not trying to fairly assess them for them; you're doing it for you, because doing it fairly is your best shot at not screwing up.


This is where the author's string of side projects comes in to play. I mean face it, it's kind of difficult to make something really cool in your spare time without getting paid to do so.


Everyone doesnt follow that philosophy, and he's advocating exploiting that.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: