nezumi

I was seriously considering Chargify, but now... I just hope they take a leaf out of GitHub's book - remember this?

http://github.com/blog/675-organizations-for-small-businesse...

It's surprising how the disease crept up on him despite the annual checks. One of the benefits I imagine successful executives must have would be super-duper, executive-level healthcare. All the check-ups and screenings the rest of us miss out on because they're not quite cheap or statistically significant enough to be worth rolling out for the general population.

And yet the CEO of a biotech firm slips through the net.

Does executive-level healthcare exist or is it just in my imagination? Is there any significant advantage to be had if money is not an issue? Or perhaps he already had all these advantages (he already knew about the genetic marker) and that's how come he's in remission now?

What's the point of having it if you don't enjoy it? This article doesn't seem to do justice to those who:

- have enough savings on hand to cover a few months' living expenses - have a sensibly invested pension plan - spend their surplus cash on things they enjoy

I'm sure the book is simply using the popular, but arbitrary and out-dated 'millionaire' tag as a hook for sound financial advice. But if your goal in life is just to be a 'millionaire', you're missing the point.

Seems quiet in here...

The trouble is, side projects go unfinished and become dormant, but they never really die - they haven't been born yet.

I love it - modern UI and a convincing tagline, I knew something like it had to be out there! (Thanks everyone for replying though.)

The scariest thing about that video is how easily they refer to Soylent as 'it', as in 'it cuts down your text', 'it fixes grammar errors', even though when Soylent is in use it's clearly a 'they'. Or perhaps that distinction is as nonsensical as referring to the bundle of neurons in your head as 'they'...

Why do you want to be good at programming? You'll only get there if you are driven by your intrinsic interest in the problems you are trying to solve. Becoming a 'rock star' is a side effect, not an end goal. The way you've phrased your question suggests you don't truly have that intrinsic interest in problem solving or building. Ask yourself what your true motivation is and carefully consider whether sitting at a desk coding is really what you want to do every day.

I'd be interested to see how the US would appear on this chart divided up by state.

"Pick a company name based on URL availability."

What does everyone think of this? I cringe every time I see another company name ending in '.ly', and I think names chosen by URL availability often sound cheap rather than clever.

I'd rather go for a name I like and pick a domain of the form <name><verb>.com, but will that be bad for business?

So HN comment history contributes to the application process? It makes sense, but as a lurker I have to admit I'm a little unsettled by it. It makes me wonder if my tendency to take a backseat and only raise my hand if I'm sure what I have to say is relevant and has not already been said, is somehow an indicator about my likelihood of success as an entrepreneur?

The first thing to bear in mind is that language learning for an adult is a completely different proposition from language learning as a child. Kids are wired for it, they have the time, and usually have external pressure to make progress. Learning methods for kids therefore tend to be slow, tedious and - because kids haven't fully developed their capacity for abstract thought - dependent on rote memorization.

My recommendation would be to start with a Pimsleur course. Don't worry about writing and vocabulary at first, just get a feel for the language. With Arabic, you have a different alphabet to learn - do that before you try learning written vocabulary, or you will be forever hamstrung by romanized transliteration messing with your pronunciation. For vocabulary, spaced repetition is the way to go. There are lots of sites and systems for this. Go with the ones that give you a high level of control over what you are studying, and train only production (i.e. going from English to Arabic), recognition will take care of itself. For grammar, here's a cute idea I had some success with in Japanese which has highly regular grammar (I don't know about Arabic): as you learn the grammar rules, write code to produce them. E.g. write a function to conjugate the past tense. When it's working, you have the basis of a game to test yourself. Use your powers of abstraction to bypass rote memorization.

Don't be down about the fact you don't manage to keep studying religiously. As long as you get some studying done, no matter how little, you are making progress. There is a lot of snake oil out there - if you find something isn't fun or isn't working for you, don't try and force yourself. Most of us learnt languages the wrong way in school, and learned a lot of bad study habits and worst of all, got the idea that it's supposed to be hard and take a long time. Not true - use your experience of learning programming as a template for what your experience of learning a real language should be like. (assuming you are a programmer, apologies if not)

There are really only a couple of uses for trivia questions in technical interviews: verifying someone's resume (i.e. if you claim to be skilled in some area, trivia questions should be, well, trivial) and as a jumping-off point for a discussion to see how you think.

So handle it the same way as you would in your day-to-day work: ask questions, try to figure it out.

If they really are just interested in your rote memorisation of documentation, consider that this might not be such a great place to work.

If you used something 5 years ago, sure you can't remember the fine details, nobody expects that. But you should still be able to discuss the technology intelligently. Even if the details are gone the concepts should still be there, and fluency in concepts is what a good technical interview will be about.

It might seem like a big scary test, but it's not. Sure, that's how things were in academia where you've been most of your life, but interviews are only superficially like tests. So the first thing is, stop worrying about the outcome and focus on the problem you are trying to solve. Not, 'how do I pass this interview?', but 'is this the right job for me?'. As soon as you start thinking like that, you'll see that you and the interviewer are there to solve the same problem, and you are on an equal footing.

The question 'is he good enough?' is just one among many - and at this stage it's the one you can do the least about, so try to let go of that. Sure, you can study long-term and increase your chances of passing certain types of technical interview. But if the job is really a good fit for you, you'll already be doing that kind of study because you're interested regardless of whether you need it for an interview.

Of course, practice is still useful. Don't just practice being interviewed, practice giving interviews - then you'll get an idea of what the interviewer is thinking. Will this guy fit in my team? Is he going to stay interested in the job?

One other tip- try and make sure you have other possibilities before you go into an interview so you don't have to feel like everything is riding on this moment.

Looks nice, although the changes are given away by hinting problems on my Linux box: http://ploader.net/files/92540a2c2b68cfe8b49f2301f628f860.pn... (I've no idea what it would take to fix this but I can provide more info about the system on request.)

Here's a nice oddball coding font for you: http://www.dafont.com/monofur.font

Is there anywhere we can get information about the failures, to try and get a balanced view? Is it time for another communal spreadsheet?

Sadly Yegge's solution to his innumeracy consisted of trawling through the same list of categories which presumably failed him at school. I wonder how that turned out?

There's a reason hackers tend not to be good at 'high school math' - it's incredibly dull. 90% of what most of us did in class consists of essentially running code, the stuff hackers expect the machine to do for us (so we can concentrate on the real problem.)

I think solving mathematical education for the general population is incredibly hard, I wish Paul Lockhart (http://www.maa.org/devlin/LockhartsLament.pdf, http://news.ycombinator.com/item?id=256176) all the best in his efforts. But I think solving mathematical education for hackers ought to be a little easier. We are eminently comfortable with symbolic languages (consistent, testable ones - I'm not sure if many mathematical notations can make the same claim), and we love problem solving. You'd have thought we'd have a hard time not becoming good at math.

Does anyone have any suggestions? How about a textbook where the methods and proofs are expressed in code, for a start?