If an insurance company provides free screening for a group that's at risk for a given disease (think Africans and sickle cell anemia), do they have to provide it for everyone? What about conditions that are more common in women than men? Does this law mean that insurance companies have to pay for yearly pap smears for men as long as they pay it for women, even though men don't have a cervix? After all, having a cervix or not is a determined by genes.
When your library of mutexes, semaphores, etc. doesn't have exactly the construct you need, and you go to write your own on top of them, it's really, really hard not to introduce serious bugs that only show up very rarely. As one random example, consider the Linux kernel team's attempts to write a mutex, as descried in Ulrich Drepper's paper "Futexes are Tricky."
If these people take years to get it right, what makes you think *you* can get it right in a reasonable time?
The irony is that threads are only practical (from a correctness/debugging point of view) when there isn't much interaction between the threads.
We using programming puzzles as part of our recruiting efforts. We put them on the subway and as ads on slashdot. We get a lot of submissions saying "I saw your puzzle on the Red line and thought I'd give it a try." One of our puzzles was linked on reddit, and that generated a bunch of submissions.
But our single biggest source of leads is referrals from people who already work here. Something like 40-50% of new hires are found that way.
I work for a company that uses puzzles to attract and evaluate people. We started doing this in the late '90s after hiring people who had good resumes and interviewed well, but couldn't program. Having evaluated a bunch of submissions, I can't imagine hiring someone without seeing a sample of their code.
Resumes have almost no information in them. Someone with "10 years of C++" might know the language like the back of their hand, or might write simple, sloppy code. Pretty much any phrase on a resume could mean just about anything.
A programming puzzle is like an audition. It's better than writing code during the interview. Writing code in an interview on a white board is pretty far from real coding: no symbol completion, no access to references on the web, a strict time limit, someone who holds a key to your career watching your every move. Only time for simple questions, and no way for the person to choose a problem aligned with their skills.
If a company asks you to spend a few hours, so they can decide whether to employ you for years, you can be sure that you'll work with people who have been similarly vetted, and they won't write spaghetti code with variable names like t1 and d2. And it can be quite frustrating maintaining code that makes www.beyondfailure.com look good.
God is a more general concept than a particular earthly description by a particular sect of a particular religion.
Your statement is more like saying that, because Mr. Picard is fiction, that the entire concept of am explorer is fiction. So, if you have a couple beers and you squint just right, God can look like anything! So you can't disprove him! (And it's always a him.) That's your argument? That's your defense?
The spiritual world can't be disproved, because any effects of the spiritual world on the physical world must be carried out through physical processes. It's important to people precisely because it deals with entirely unscientific subjective concepts, such as the concept of a soul; whereas science necessarily deals with objective concepts: those that can be independently reproduced and verified. So, how do you know that anyone other than you has a soul? As you've said, there's no objective way to tell. No way from the information that comes to your senses, from the sounds and lights and smells. How do you know that other people aren't robots? http://en.wikipedia.org/wiki/Cogito_ergo_sumCigito Ergo Sum?
You can believe that a particular description must be wrong because of the religious bootstrapping problem you describe -- that is: once touched by imperfect humans, then passed on by imperfect languages, there is likely to be a mistake somewhere along the line. But you can't use that to refute the more general concept of God. Scientific understanding comes from http://en.wikipedia.org/wiki/Scientific_methodScie ntific Induction. Basically, if the sun has risen every day for as long as someone has looked, http://en.wikipedia.org/wiki/Occam's_Razorthe best bet is, it will rise tomorrow. (Ok, we abstract from such things to general relativity. So since general relativity has always seemed to hold, we assume it will tomorrow.) Being an atheist is about the same leap in logic as believing that the sun will rise tomorrow: just because it has, that's no proof, right? Have you put all your affairs in order in case the earth can't support life tomorrow?
There, I said the "A" word.
Thanks; what kind of scenarios would you suggest?
I ask people about their management philosophy, but for people who aren't very reflective, they don't have a lot to say. There are those who like to read, think about their approach, and reflect. They can have a lot to say about management philosophy. And then there are those who know how to handle any situation put in front of them, but haven't distilled that into a philosophy. Like people who did agile development before there was a word for it.
Slashdot Mirror
If an insurance company provides free screening for a group that's at risk for a given disease (think Africans and sickle cell anemia), do they have to provide it for everyone? What about conditions that are more common in women than men? Does this law mean that insurance companies have to pay for yearly pap smears for men as long as they pay it for women, even though men don't have a cervix? After all, having a cervix or not is a determined by genes.
- There are often other ways to do it, e.g. multiple processes communicating over sockets, or multiple processes that share memory.
- Threads are hard to get right. Really, really hard.
When your library of mutexes, semaphores, etc. doesn't have exactly the construct you need, and you go to write your own on top of them, it's really, really hard not to introduce serious bugs that only show up very rarely. As one random example, consider the Linux kernel team's attempts to write a mutex, as descried in Ulrich Drepper's paper "Futexes are Tricky."If these people take years to get it right, what makes you think *you* can get it right in a reasonable time?
The irony is that threads are only practical (from a correctness/debugging point of view) when there isn't much interaction between the threads.
By the way, I got that link from Drepper's excellent "What Every Programmer Should Know about Memory." It also talks about how threading can slow things down.
They're spending a year dead for tax purposes.
We using programming puzzles as part of our recruiting efforts. We put them on the subway and as ads on slashdot. We get a lot of submissions saying "I saw your puzzle on the Red line and thought I'd give it a try." One of our puzzles was linked on reddit, and that generated a bunch of submissions.
But our single biggest source of leads is referrals from people who already work here. Something like 40-50% of new hires are found that way.
I work for a company that uses puzzles to attract and evaluate people. We started doing this in the late '90s after hiring people who had good resumes and interviewed well, but couldn't program. Having evaluated a bunch of submissions, I can't imagine hiring someone without seeing a sample of their code. Resumes have almost no information in them. Someone with "10 years of C++" might know the language like the back of their hand, or might write simple, sloppy code. Pretty much any phrase on a resume could mean just about anything. A programming puzzle is like an audition. It's better than writing code during the interview. Writing code in an interview on a white board is pretty far from real coding: no symbol completion, no access to references on the web, a strict time limit, someone who holds a key to your career watching your every move. Only time for simple questions, and no way for the person to choose a problem aligned with their skills. If a company asks you to spend a few hours, so they can decide whether to employ you for years, you can be sure that you'll work with people who have been similarly vetted, and they won't write spaghetti code with variable names like t1 and d2. And it can be quite frustrating maintaining code that makes www.beyondfailure.com look good.
Thanks; what kind of scenarios would you suggest? I ask people about their management philosophy, but for people who aren't very reflective, they don't have a lot to say. There are those who like to read, think about their approach, and reflect. They can have a lot to say about management philosophy. And then there are those who know how to handle any situation put in front of them, but haven't distilled that into a philosophy. Like people who did agile development before there was a word for it.
Middle managers, directly managing around 10 people who write code, and reporting to the product manager.