azanar

The problem here is a fundamental misunderstanding by your new coworker of exactly how the employer/employee relationship works, as opposed to how he, or really most people, believe it works.

In his understanding, the relationship stops with the employer, and the employer is paying for his time the same way he might pay at a meter for parking his car. What he's doing while his car is parked will vary, but he is expected to pay the same amount at the meter per unit time regardless of how worthwhile being parked there is to him at any point in time. In the same way, an employee is paid for seat time. The service he provides to his employer may vary depending on what the employer has him doing, but he expects the same remuneration regardless.

I suspect by your confusion, you see the same misunderstanding as I do. The relationship chain does not stop with his employer; instead it recurses out one or more levels from there until it reaches a customer paying for the product. This is where the value of the work is realized, when you find the person who will purchase the good or service on behalf of themselves, rather than on behalf of someone else further up the chain. More often that not, this last person in the chain will end up paying based on something other than time. If this customer refuses to pay more than employer is paying for your time, you are not productive enough, regardless of what sort of sense of entitlement to employment you think your diligence and hard work provide for you. You cost more than you produce; thanks for playing.

If you generate enough value for the actual customer that your employer is happy with the cut they get, then it absolutely should not matter how many hours you put in to generate that value.

It really comes down to a question of which is more important in being an employee: the value you produce for your employers customers; or how well you demonstrate your willingness to work hard, be a team player, demonstrate a strong work ethic, be diligent and obedient to the chain of command, or any of a myraid other things that might increase the value you produce to your customers, but are not the same thing as producing value to your customers.

The market is brutal; it couldn't care less how pious and moral you are.

It's possible the organization encourages people not to linger in the sense Alex Papadimoulis discusses in http://thedailywtf.com/articles/up-or-out-solving-the-it-tur...

Of course, getting the why of a turnover rate is hard; an employer with a culture that encourages negative turnover probably won't be willing to fess up. That probably involves contacting enough former employees to get a non-biased sample, and convincing each of them to be honest. That is, if they are willing to talk to you at all.

Do you have any insight about the motivation to settle for slim profit margins?

This seems counter-intuitive, unless by shrinking margins, they make a significant increase in the bottom-line. (i.e. they would rather make 1% of 40 billion than 20% of 100 million)

Is this sort of trade-off common? Does it work out favorably often enough that it can be backed by something other than managerial fashion?

They do this simply because that is the only way for them to either get the talent of the startup, or get a competitor to start working on their behalf.

If the startup is successful, I doubt the founders would be particularly interested in giving it up without some compensation. If it isn't successful, then it doesn't matter, since Google will be able to recruit them for far less money once the startup is dead.

It is in every company's best interest to pay the people they hire below market rate for their work. The only benefit Google gets from this is that they know the people they recruit through acquisitions are capable of building things. It's a trade-off: is it better to acquire a company, knowing the people aren't losers? Or is it better to avoid having to pay market value, at the risk of picking up a loser every now and again?

I wish this were true. The impression I get is more of numb, passive contentment, at least from enough people in this demographic that it is bothersome. They seem to have traded happiness and fulfillment for the image of happiness and fulfillment, and it is difficult to tell the difference until you ask the hard questions that make them feel uncomfortable and defensive. That's why most people don't, and that is why the groups are assume to intersect perfectly.

There are things in life one must attend to that likely force people to get 9-to-5's. You know, like a wife and kids.

How much of this is a must, and how much is a result of choices they made? And how much of this forcing is a result of emotional and social pressure, as a result if imminent, tangible risk? That is, how much is a result of wanting to convince others that one is a responsible parent, as opposed to one actually being irresponsible?

That you find joy in your family is fantastic, if only because you've found something to enjoy. That your boss has been slogging away for ten years on his business is fantastic, as long as his enjoyment of is worth more to him than the things he's not done. So long as he or you don't regret it.

The important difference is between compulsion and choice; or even more dangerously, a choice that is made, and then justified retroactively as a compulsion.

It isn't worth itemizing all of the things people are compelled to, except that this list is a somewhat abbreviated version of them: get a good (read: easy) 9-5 job; spend money as catharsis; and let other people take the lesser worn path and, if they succeed, live their joy secondhand as much as you can. Also on the list: having a wife and children. They are defaults, and I'm not the first to say that defaults can be quite compelling, and can be just as easy to pass off as compulsions afterward.

Keep in mind, these being external compulsions does not mean that everyone does them for that reason. It just means you have to be more careful about how much of your desire is actual desire, and how much is just aimless drift.

Doing things just through compulsion rarely leads to enjoyment. It might have been when the compulsions weren't just compulsions, but a lot of what we feel compelled to do is fossilized wisdom from what other people would have thought would make them happy, and maybe it did for a few people. The rest are still waiting for the pay off, or have just given up and have become satisfied being content and comfortable.

I don't think most people have to settle. I think the problem is a higher level than the author gets at in his essay: even when people have options, they feel compelled not to pursue them. In the worse case, they feel compelled to destroy those options -- I've seen this happen, and it is tragic. I don't think it has to be this way.

I don't think you're doing wrong, btw. But your comment reminded me of all the times I've seen people sacrificing to compulsion at the expense of fulfillment; it seemed worthwhile to get those thoughts out there. :-)

My condolences to you jemfinch, btw, and anyone else from Ning lurking on Hacker News. Not the best day for any of us.

For those who might be recruiting, I am also looking for new opportunities, especially in the Seattle area. I see myself as very much a generalist, both in the sense of technologies and languages -- and being able to pick up new ones quickly--, and in the sense of being able to act as other parts of an engineering staff (sysadmin, qa, etc.) when called upon. If you want more details, feel free to contact me -- details in profile.

The logical precursors of this is that technically minded people are either not capable of analyzing business decisions, or that they shouldn't be allowed to anyway because they are technical people. Perhaps both.

If they were capable, there would be no reason for a PM to be firm on a business decision, because the technical staff wouldn't run nearly as high a risk of pushing him to do something stupid.

If we assume they are capable, then this becomes an argument to authority. I would then like to ask the following question: if the people who watch the bottom-line see an improvement based upon a particular decision, do you really think they'll care who made the decision, and what influenced them?

I've never understood this bright line boundary between the patchwork of people that make up a technical group, and the patchwork of people that make up a business group. Presumably, the technology being developed is part of what makes the business viable; it isn't just a bunch of people wanking off in text editors on company time, while the grown ups -- the business folks -- do everything that earns money.

It serious just seems like an artificial division to excuse the two groups for not listening to each other.

This becomes even more painful when you are one of the people who wants to be involved in whatever makes up this nebulous "business side", and are told to fuck off back to your toys.

My view: the business is everyone's business, and any time you start developing bright line boundaries to either protect turf, enforce a hierarchy for its own sake, or excuse non-involvement, the least of your problems is one of your techies wanting to play with technology that seems superfluous to the untrained eye.

It's interesting how two different perspectives on what is largely the same arrangement can yield such different answers.

By organization, if someone can fire you, you are their subordinate. By productivity, the "subordinate" is not necessarily subordinate at all. The working relationship may be much more than of peers, where the pair of them manage to both get things done, and keep people informed of what is going on. It might even be that the subordinate in the traditional sense is anything but in the tangible sense.

What sucks is that the traditional organizational arrangement has a very difficult time representing this. It mandates a strict hierarchical arrangement of staff, even if the staff themselves does not view themselves as hierarchical.

Because, in this arrangement, one person is usually granted the ability to terminate the employment of the other, there is necessarily an adversarial component to their relationship. Even if they work as peers, one has to report to a chain-of-command about the other.

For people and teams who don't need this sort of arrangement, having it imposed absolutely sucks. But, because it so entrenched in corporate tradition, it emerges anyway.

I rail against it as well.

There are people who don't need it, but those who don't need or want this arrangement get it anyway, regardless of the detriment it causes. I get the sense this happens simply because of the perspective that it must necessarily happen, because people have all these preconceived notions about management and subordination that they have a hard time letting go.

I think we'd lose the adversarial perspective if we lost the notions, and that would be a good thing.

Many people tend to see deliberately introversion and aloneness as deliberate alienation. It's a cognitive leap that still confuses me; people assume a behavior that isolates the individual is out of spite for the social collective, even if the person carefully explains that they aren't doing this out of scorn but out of personal need or desire.

My suspicion is that aaronsw is just describing his relationship to those around him the same way they would describe it, but in more matter-of-fact terms. That he seems to have offended people so makes me think he touched a nerve, even if it did it tongue-in-cheek. My first reaction to this is to start reflecting on the social biases we have which would cause us to recoil in such disgust to the suggestion; are we being unreasonable in our expectations of the people around us?

I don't think that, even for people who actively sacrifice human contact to read, that it is an end to itself. It is possible that they are also building toward a better life, but that their concept of a better life does not include being in the presence of others whenever possible with something to share. Their better life might be one where they can spend time in quiet contemplation, and reading is the fuel for that contemplation.

Some people are just not that gregarious. And some who are gregarious find that it is a tendency that interferes with their goals.

The pressure for people to be gregarious is intense, though, and it is harder for those who aren't natural social butterflies. The natural tendency might be for someone to soak up an enormous amount of time reading. Because of the pressure to constantly be socially on-call, they have to make the choice seem much more deliberate. As a result come off as someone with an anti-social disorder. The result would be the same, but because we brand the end as less than desirable, they get cursed for their means. Either way, they get patronized, which simply isn't conducive to anything but antagonism.

This may not be the thought pattern aaronsw is following; I don't know. He might be actively fighting a natural extroversion because his goals don't align with his extroverted nature. I'm rather strongly introverted as a natural tendency. He may make a deliberate choice, while I drift, but am forced to make it seem at times a deliberate choice. Same ends, different means.

Nevertheless, the net you cast to catch him caught me as well. I suspect I have much more to understand about the naturally gregarious frame of mind, and would enjoy a discussion toward understanding. I'd also enjoy a discussion toward others understanding the less gregarious amongst us. I don't think casting an unusual or confusing behavior as 'sad' is going to help at all in understanding; it indicates a mind already made up. I'd rather be misunderstood or confusing than sad; then I'm not forced to apologize just for the opportunity to explain.

Have a look at the job link posted by ohlol for descriptions of these positions as well.

The biggest concern I have is that he account nowhere for growth of that new feature, and the increasing hosting costs as a result of that growth. Part of efficiency is how fast is it now; the other half of efficiency is how will the performance change based upon an increased load.

Part of the risk of putting out a new feature is you don't entirely know what the uptake will be. It could fall flat, it could grow exponentially within the first week. Or, as this author assumes, it could enjoy a rapid uptake of a certain amount, and then level off just as quickly. I'd argue this last possibility is almost never the observed pattern.

The other part of the risk is that, if you go the inefficient route, you may not have the time later on to even build bad hacks within the inefficient code to make it speedier. This is a bad situation to be in, you end up getting screwed by your own unexpected success, and users get pissed because now your site is unreliable.

Yes, spending insane amounts of time on efficiencies probably aren't worth it. Yes, you need to do cost-benefit analysis to decide what amount of time is. My point is that there is a lot more to consider than the author gives credit for, and I don't think you are as likely as he believes to reach the same conclusion he did. Cash flow is important, but it is also important to remember that things don't remain flat or grow linearly just because you assert that they do.

There are certain things that just don't work right when using the Apple provided interpreters for particular languages, even if the versions are right. Though I don't recall anymore what the specific problem was, I recall needing to install a custom build of PHP to get a particular library I depended on to work. I wish I could remember more of the details. The point is that I can understand a modest amount of distrust for the built-ins.

There's also the matter that the internal versions of the interpreters run the risk of becoming dated, staying that way, and perhaps becoming so dated that the needed code can't run without later version of the interpreter than the OS provides. Discovering whether it is "too dated" sounds like a fragile process, you'd have to either parse the interpreter version or make assumptions based on OS version.

The solutions I see available are: to leave it up to the user to figure out if a newer interpreter is needed, or just assume the internal interpreter won't work and build your own that you're much more certain will work. This comes down to a matter of philosophy, where MacPorts says "we'll figure it out", and Homebrew says "we trust you know what you are doing."

I found the Python issue to be a particular pain in the ass, since MacPorts's Python build requires tk, which requires some GUI libraries, which ends up building more or less an entire X11 sub-system on OSX that I will never ever use.

This seems like more of a criticism for the python port maintainer than the entire build system. It might be worth posting a request for Tk support to be made a variant of each of the python ports.

This becomes a much larger problem if something runs things from /usr/local with increased privileges -- something from launchd run as root, for instance.

I was originally thinking just from the perspective of the active user, but a lot of things get run without the logged in user's knowledge, and with a varying level of privilege.

Ok, yeah, I agree with the original poster of this thread: yikes, time to start chmodding things.

Say for instance you have a dev server, so security isn't as big a deal* used by a team of people, all of whom would want access to the same basic packages. It seems that /usr/local/ or some other world-visible place would be the location for this stuff.

That you don't have to be root is the same way that you don't necessarily have to be root to install programs in the usual MacOS way of running a GUI installer. If you are part of admin, you're already privileged to sudo anyway, so the protection you get is primarily psychological; you type 'sudo', and it triggers the part of your brain that pays much closer attention to what you put on the command-line.

But as I mentioned to rbanffy, it is very possible I am missing a key risk that makes this a very bad thing to do. I am open to enlightenment. ;-)

I suspect that there are security implications regarding this when done on more of a server-style environment. Perhaps that is what you were saying 'Ouch!' about?

Or maybe you were thinking of another pain point that isn't occurring to me right now?

Since this article is pretty much dead, you can hit me up by email if you're interested. :-)

Given a particular frame of mind, though, this is perfect.

These complicated designs are about keeping their current jobs. They are making more work for themselves and those around them, and that is entirely the point. They aren't looking to their next job, they are looking to assure there will always be a next task. If they didn't create complexity that need to be constantly coralled, they might run the risk of the project being declared complete; yes, a risk.

The problem is their frame of mind about their professon. If the project is completed, one of two things will come true:

1. They will be moved to a new project.

2. They will be dismissed from the company, and have to find a new company and a new project to join.

So the second is really just a degenerate case of the first. They will be on a new project. There are a few reasons people would honestly be scared of this.

They might assume that there is a small number of projects left, and they are all near-fully staffed. If they lose this current project, it may be the last project they ever find themselves on, because no one needs anything built anymore.

If they find a project, they can't coast. With their current project, they are applying design and refactoring patterns they already learned to a system they already understand. A new project means they'll be faced with an unfamiliar architecture and code, and their usual ways of looking busy aren't going to work until they learn the new system well enough. It means they have to start thinking about what they are doing and start working hard again, and there are a lot of programmers -- and people in general -- who are really averse to being forced out of a routine process they can perform without thinking.

A new project also means they might end up under competent leadership, who can tell when they are coasting, and will call them on it. This means, even if they learned the system well enough to know where to start blindly refactoring to patterns, they wouldn't get away with it, because the people supervising them would know they are just wasting time. Again, a lot of people won't like this.

Finally, a new project means someone might expose themselves as completely incompetent and faking it well the whole time. They picked up enough bits and pieces to sound intelligent to those who don't know how or what to judge, but just for the project they were on. The specialized jargon is now irrelevant, and the general understanding of concepts isn't there.

Even in my short journey so far as a developer, I have run into multiple examples of each of these, and they annoy me to no end. The ivory tower systems Zed is railing on about are just a symptom. The cause is people terrified of being forced into unfamiliar territory, and the risks involved.

The other part of the problem is that the people who judge the programmers are not listening to the masters -- as much as we have masters-- even when the masters kick the experts' ass. Perhaps this is part of our profession needing to grow up, but right now programmers are judged in most places by people who would be audience members at a martial arts tournament. They have no idea about the technical skill of what they are seeing, and so they can only judge things on aesthetics. To them, the experts look talented, because they are doing a tremendous amount of moving around, acting threatening, and expending energy; the masters look lazy and unskilled by comparison. It almost looks like the master has to be cheating when the expert gets slammed to the mat. I wonder if the audience to a master programmer might perceive the same thing.

A question which I am still uncertain of: is this reliance primarily on the aesthetic instinctual, or is it learned behavior? It seems to be responsible for a number of extremely poor judgments made, even in very recent history, and I think it is worth asking if such a reliance is inevitable. I'm not dismissing aesthetics entirely, just wondering why we seem to have it weighted wrong.

First impression: way too much pimping, way too little describing. The front page seems more focussed on who uses it and how awesome they think it is than on what it is. I have a vague idea from your bulleted list, but no idea what differentiates this from all the other CRM systems. The companies you list might, but that is of no use to me. I'm not about to waste my time and contact them to tell me what you should have told me. The video might tell me, but I'm not compelled to watch the video. That combined with the odd and elongated layout would have the average customer uninterested in learning any more about the product.

Specific things: * Please, please remove the scrolling images part of the way down. They are distracting and get annoying after more than a few seconds. * Your page goes on below the fold on a 1024x768 monitor, and you have marketing content below that fold. This is very bad. I would honestly take the box of specific features and shove that near the top. In fact, that and a 2-3 sentence description of what the product does is all I could imagine being necessary on the front page. The client list and press hits could either sit at the bottom, or go on another page. * The page flow is very odd. I'm having a hard time figuring out where my eyes ought to be going. There is that weird block of white space right below the press icons, and on either side of that irritated scrolling thing, which make it hard for me to keep track of where I am on the page. I get the sense that you could solve the page flow problem the need for scrolling at the same time, just by taking advantage of the space you haven't used yet.

I should add the disclaimer that I am not a professional designer, and so some of the things that bother me might be considered good practice by people in the know.

Hope this helps.

But I do have a question regarding a couple of the items on your list:

===

1. Sodium Nitrite.

Through carelessness, it can result in the production of carcinogens; in large quantities this can cause cancer, but the AMA states that there have been no cases of food consumption induced cases of methemoglobinemia -- most of the cases have been due to contaminated water or accidental overusage in food. It has has been linked to migraines with those already showing a tendency. There is also a possible link between COPD and this substance, but the question is still largely unresolved. So there are risks, but only under particular circumstances. And, evidently, there are some things it treats effectively. It's worth being cautious about, perhaps, but not necessarily phobic of. Is there some other risk I am missing here? What is the additional cost involved of eliminating sodium nitrite? Is it worth it, considering that it prevents the growth of some really toxic bacteria?

2. Artificial colors (and some flavors, maybe?).

There is some suspicion that some of these colors might result in an increased instance of ADHD. Is the data reliable? What about the studies that suggest no correlation? Ask I asked in question 1, what are the additional costs of eliminating these? Since we may not color otherwise -- it is just aesthetic, after all -- what are the potential cost savings? Are they worth it? Any other risks I am missing? Same questions.

3. MSG.

Same concern as NaNO2 about migranes, and a possible link to obesity. Both of these appear inconclusive. Same questions as NaNO2.

===

There are a few other things I need to research more before I can asked good questions about them. And some of your advice I have no questions about; I'm already aware it is good advice. :-)

I'm not asking these just to be deliberately provocative; I think they are important questions to ask. A rambling train of thought on why I decided to ask them:

The people I know who really obsess about what is in their diet are, on average, the most unhappy, neurotic people I could imagine meeting. They spend much of their time avoiding disease and increasing longevity at the expense of enjoying life and not worrying so much.

Sure, they could just punt, and buy everything at the most natural store they can find, but that is really expensive.

To account for that added expense, they now have to find work that pays better, which for many people means compromising on a number of other intangible factors. These can play havoc on a person's frame of mind, and cause a variety of other health consequences.

I may not be speaking for many of the people here; I suspect the expense is something a lot of us -- including me -- could bare without a lot of trouble and without sacrificing much in quality-of-life.

But I don't think the average HNer is representative of the larger population.

Example: one friend of mine, neurotic about his diet, quoted me a grocery bill of over $600/month on average. You can probably imagine what sorts of items he buys regularly

This a remarkable sum of most peoples' take-home pay. If they bought food this way, the money they spend might increase their longevity; we've had threads on here in the past arguing that this budget is worth every penny. However, it might also severely hamper their quality-of-life; it might even start to hamper their ability to pay for what we consider necessities.

In the case of the friend, it was a significant chunk of his take-home pay. He constantly found himself strapped for cash and falling into deeper levels of depression as a result. I'm not sure if he was making the net positive trade-off. It sucks that he had to make that trade-off at all, but that is several political squabbles from getting solved.

I don't mean to discount any of your advice. In good circumstances, it is well thought out and well researched advice. I follow at least some if it myself, and probably should follow more. I'm making a note to add blueberries to the next shopping trip, even though my cholesterol was ok last time I had it checked -- they're tasty, that is reason enough anyway. :-)

But I think it's worth mentioning that this problem goes deeper than just individual people passively ignoring advice. As even Dr. Lustig pointed out, there is manipulation going on behind the scenes, and some people may not have the means to effectively fight against the manipulation and still feed themselves.

And it's also worth asking for clarification, even if one can make a change without an undue burden. Asking questions is always a good idea. :-)

Sigh. I could try to convince you that your personal observations are not representative, and you could probably tell me the same thing, and we would end up yelling past one another. We could both scream for data, and probably disregard the data that doesn't back our viewpoint and continue yelling past one another.

The problem is that we both have a vested interest in believing what we do. You've already admitted that you have a GPA that probably would not satisfy most hard-line GPA targets. I'll admit up-front that my GPA likely would satisfy most company's targets; this means I already lose a gold star.

This is a shame. I have not drawn any conclusions just from your self-confessed low GPA, but you have already prepared to consider me irredeemable. I'd probably ask some probing questions, realize that you've been bloody busy outside of classwork, and not think too much of it. This strategy could work both ways, for what it is worth.

I could just decide that if I were rejected at a company where you were vetting me, I am perhaps better off not being there. If I were hired, I'd have to deal with the chip on your shoulder about how I have already shown I can't hack because of some single arbitrary metric. But that would be out of the spirit of this site, and would assume things that probably aren't true about the users. So, instead, I'm going to try to provide a counter-argument.

Here's what I can say in my defense: I got that GPA without really giving a damn about my GPA. I found the topics I was working on fascinating enough without the motivation of grades, and got good enough at them that I was able to perform well on tests and assignments anyway. I guess I could've gone farther and just not done the assignments and skipped the tests, but requiring that much disinterest seems petty.

I wasn't trying to prove myself to anyone. And I still found time to play with things and hack on things of my own outside of the classroom. The only big strike against me, perhaps, is that I didn't get involved at all in open source until later on; I never published most of the things I was tinkering with in college. It doesn't mean I wasn't tinkering though, just that I wasn't public about it.

On top of that, I had an entire network of machines in my dorm room that the administration would've thrown a fit about had they known; I can only imagine what the power bill looked like. Having this taught me a bunch of things a networking theory class never would.

On the other hand, my networking theory class allowed me to make connections from experience to theory that made a whole lot of other things become obvious almost as soon as I was exposed to them. I drag this quote out from Deming all the time, because I think it is the best argument for not just focusing on the immediately practical: "Experience by itself teaches nothing... Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning." FWIW, I haven't stopped learning just because I left college; to be honest, I think I would go stir-crazy if I did.

Hopefully, what I've written above makes some sense. Unfortunately, I've been shot by your generalization, and would not have been able to explain any of this had you said this in a group where you also controlled admissions. I think hard grade cutoffs in both directions suck, because they make a universal predictor from a weak indicator of arbitrary performance through unknown motivations.

Please, for me, and those like me who arrived where we are without the motivation of sucking up to our superiors and fitting the mold, don't be so hasty at nailing us to the wall. You'll just end up cultivating bitterness, and groups of people who don't want to work with one another based on something completely arbitrary.

What of the developer who works on something ambitious that ultimately flops and becomes a total write-off for the company or client? What of the developer who coasted along doing nothing on a team of people who built some billion dollar product? What of the developer who can't really itemize their contribution in dollar amounts because they don't have the foggiest idea how much in dollar amounts they contributed, apart from how much they charged for their time?

Failure on a project is not a communicable disease that spreads to other projects through developers; success is likewise. Failure is so common that a developer without decades of work experience runs a non-negligible risk of not having a big success. And having a big success does not predict with a high degree of certainty future successes.

To add to the trickiness of this problem, we can't just tell people "sniff out projects that smell of failure, and avoid." How would they know? Developers are not clairvoyant, so the solution to this is to use heuristics. Some of these heuristics are unique to one individual who got burned in some particular way. Some are as ubiquious as development best practices. Either way, they can be wrong for a particular context, or sometimes wrong in general but kept in peoples' minds by inertia and repetition.

This is a harder problem than just quoting dollar amounts, and assuming that zero net dollars means zero talent. I can't help but think that when someone can put on their resume "Built a site that made $x million dollars," it may be as much a reflection on their luck of being at the right place at the right time as it is on their ability to execute after finding themselves there.

Curiosity and genuine interest develop at different times for different people depending on the circumstances of their life. They might have not discovered programming until later in their life, or they may have been soured by an bad experience early on and only came back later on.

For some people, they don't discover programming until university, but then find the absolutely love it and quickly develop a considerable talent. For these people, who do exist, the pre-university test is a false negative.

A lot of these tests people come up with are based on the concept that past performance indicates future potential. The thing about these tests is that they suck really bad, except that for certain things there are no other tests.

A meteorologist I once heard talking about weather phenomena in Alaska joked in his talk about how there are two possibilites for available weather data there: data sparse, or data void. It is much the same in finding good programmers. There are a lot of important considerations, and getting a feel on each depends on sparse data at best. The best advice I can offer is don't take things like this too personally. Following advice from pg almost certainly applies to applying and interviewing for jobs as well.

Don't be put off if they say no. Rejection is almost always less personal than the rejectee imagines. Just move on to the next. (This applies to dating too.) - Paul Graham, Undergraduation.

Just take it as a sign that they probably would be judging you even after you are hired in ways that you might find unreasonable. Not every hacker is meant for every programming job.

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.

Unless you are presuming a team of only a couple of developers doing their own thing, there is a real challenge in determining the extent of the programmer's responsibility for something that is exposed for all to see.

There are a number of other causes that might make a site a developer helped work on look or run like complete garbage. Organizational inertia might have forced the site into sucking, regardless of how good the programmers developing it were. The organization may have one or more bad programmers who were assigned to work on some critical component, screwing the whole site and all the good programmers.

We can wax on eternally about how the good programmers in this situation should've seen the writing on the wall and gotten out as soon as possible, but that's very easy to say seated in armchairs gazing from afar. Maybe they thought things were going better than they really were; maybe they saw things going bad, and thought they could motivate others to turn things around before things become a disaster -- and maybe they failed trying to do that[1]; maybe they have been trying to get out, but they are already tainted by the bad work of the organization that has become part of their image as well.

They could do work outside of their employer, for instance on an open source project, but these can succumb to the same sort of pressures that push profit-seeking organizations toward mediocrity. A single developer, even a really willful one, will have a hard time overcoming this inertia.

[1] At one of my prior employers, I was in this boat; I both tried and failed to get things turned around. I did quit, but probably not soon enough to convince people that the site was not a reflection of me and my standards. The site was absolutely shameful, and I'm sure anyone who used that site to infer things about my skill level would've sworn I had no skill or experience outside of a weekend PHP crash course. Granted, it would vet one organization I would probably not want to work at; but it would represent wasted potential based on presumption, which is a shame.

I really think the details matter, because they are a chance to determine if the work you are using to assess the programmer is spurious input, and reflect an influence largely made up of things other than that programmer.

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.

A few other patterns may make appearances, depending on the organization, but the practical upshot is something a former manager of mine kept on about regarding working at large, asshole driven organizations: focus only on requirements. Do precisely what you are told to do, and precisely what you are told to do it on, and do absolutely nothing else to anything else. For developers, this involves fixing or implementing precisely what the bug ticket tells you to, and committing precisely that to the repository. For the tester, this involves testing precisely that feature or fix the ticket indicates, and not suggesting in any way that another related fix could be rolled into this one with little effort. For the project manager, this consists of having endless meetings with people to make absolutely certain the items on the task list are prioritized correctly, and dragging developers and testers into those meetings to project an image that your organization is "engineering driven".

Expect that if you violate this tenet, you will face unwanted consequences, even if things turn out well for what you were working on. It doesn't matter that you made things better for the organzation; you usurped the task-delegation authority of someone else, and it is quite possible that person was hired for that specific purpose. If you show you can self-manage, this person is now redundant, so it is in their best interest to show you can't self-manage by making sure you are scared completely shitless of ever doing so. Vague threats and social politics work well here.

But it's not that the individual wants to abide by these particular patterns; it's that they are wedged into a political canyon. They know that whatever effort they might put in to making things better will result in them being fired for insubordination as soon as someone finds out what they've done. Would they like to keep their job and deal with a horrible codebase, or would they like to lose their job and have nothing but the bitter taste of a horrible legacy codebase you can now do nothing about.

These are all symptoms; the cause I've always seen is that the staff are scared shitless, and want to make sure no one can hold them responsible for anything. It seems to me that if you get rid of that, you get rid of the catalyst behind a lot of these other problems.