> Hopefully they are just a recompile away from being fixed.
Have you ever tried to recompile a big pile of crusty, 25-year-old code that was only originally intended to be used for five years on one very specific platform and has not been recompiled since the last OS upgrade more than ten years ago?
It's not unusual to get tens of thousands of compile-time errors.
That's assuming nobody deleted the source code six years ago to make space on the old hard drive because the log file had never been rotated and all they knew was the hard drive was low on space and the source code was the only thing they were pretty sure they didn't need on a day-to-day basis.
> I'm mystified why it has to be a webcam, other than the joy of complexity.
It's an example of the X Y problem, documented thoroughly here: http://www.perlmonks.org/?node_id=542341
Complexity has nothing to do with it. People see advertisements for uber-cheap webcams, know that webcams are designed to be hooked up to a computer, and think to themselves, "Maybe one of those things will solve my problem, and I'll only be out eight bucks!"
The question _should_ read, "Dad can't read anything less than a 36-point font, and his vision keeps getting worse, but he loves to read books. What's the cheapest way to solve my problem? Will a cheap webcam somehow solve this? Some other option?" But most folks don't have enough experience with tech support (or in some cases just plain don't think clearly enough) to know that they should word the question that way.
No, no, no. You don't _fire_ the employee. In fact, give him a commendation for original thinking.
Then eliminate his current position by outsourcing it to the contractor, and reassign him into a newly created position in the Labor Outsourcing department (a subdivision of HR) -- on commission, so that in order to maintain his former salary level he has to outsource the job of one of his (now former) coworkers every week.
And, if you want to be really evil, feature a story about it on the front page of the employee newsletter.
The problem is that almost all currently available ebooks have DRM that ties them to one account and a small number of reader devices, in clear violation of the First Sale principle but backed by the anti-circumvention wording in the DMCA.
Currently the only way libraries can lend (non-free) ebooks _without_ lending the reader is through a contract with a company called Overdrive (who in turn have some kind of deal with the publishers). The way the Overdrive setup works has so many drawbacks and problems I won't even try to start listing them, but I'll summarize: it appears to have been deliberately set up so that library ebook lending will certainly fail to ever catch on in any significant way.
There have been rumors that at some point there may be a competitor to Overdrive, but I've yet to see anything concrete, and even if there were a competitor they'd still be bound by all same bizarre limitations the publishers have put in place. Competition in this market might improve some superficial aspects of the experience (e.g., the difficult-to-navigate Overdrive website), but the basic nature of the deal would be unchanged.
> elegant, easy to read, and maintainable > You mean rewrite it in another language?
Almost.
There are almost two entirely different Perl languages.
Perl code can be truly awful when it's written by people who are new to the language, have their thinking dominated by lower-level languages (notably C), or are just plain bad at writing code. I've seen some of that code. It's bad, no question about it. It makes my brain hurt. When I see it, I always get this urge to rewrite it in Perl.
(Okay, actually, there are _three_ Perl languages. Deliberately obfuscated Perl is even more difficult to read than badly written Perl, though it tends to be interesting and impressive and even fun to read, rather than just making you want to bang your head against a rock.)
> so it's a panic test, but you give them time enough to not panic?
You give them enough time so they don't _need_ to panic. Some people will still panic, even though there's plenty of time. You don't want to hire those people.
There are also additional things the test can uncover besides panic. Completely lying about having any ability to program at all is one.
That'll really only be a problem during the transitional period when only a couple of ISPs are doing NAT. I predict that within another decade virtually *all* ISPs will be doing NAT, and so websites and other services will just have to retool their thinking to take into account that most users are behind NAT.
> And how can the customers of the ISP run servers on their computers?
Most consumer ISPs officially don't allow that anyway. (They don't usually police it actively, unless your home server gets enough traffic to be noticeable. But the rule is on the books in most cases.) If you want to run a server, you're theoretically supposed to buy business-class service.
Honestly, I don't see a problem with ISPs levying a small surcharge (a few cents a month) for a public IPv4 address. Most people have no use for it. I personally do have a use for it (I like to be able to ssh into my home computer for work), but I'd pay a few cents extra for that, as long as the price is reasonable. Heck, up to a dollar a month would be reasonable IMO, simply because it's not that much money compared to what you're already paying for other services (chiefly, bandwidth and dubiously useful tech support).
And I *certainly* don't have a problem with ISPs only giving public IPv4 addresses to customers who actually ask for one. Take all the people who just want to get on Facebook and watch stupid videos on YouTube and put them behind NAT. They won't notice, and they won't care. If somebody tries to explain it to them and convince them that they've been wronged, their eyes will glaze over in boredom.
Actually, ICANN should cover its administrative costs by charging the regionals for IPv4 assignments in large blocks, instead of handing them out for free. A rate of one cent per allocated address would raise tens of millions of dollars each year. Then the regionals could cover *their* administrative costs by marking the price up slightly, and the large peered multinational ISPs who have the big blocks could mark them up just a little more, and by the time you filter down three more levels to the consumer we're still talking less than a dollar a year.
And that should be plenty to ensure that everyone has as many addresses as are actually needed, because they're not actually scarce. They only appear scarce because until now they've been handed out for free in unlimited quantity, and so *most* organizations are holding more public IPv4 addresses than they have any real use for; in many cases, multiple orders of magnitude more than they have any legitimate use for. I say, charge them a few cents per address and see whether they *really* need a Class A network for their three servers and two offices full of workstations.
Punishment is, ideally, not supposed to actually _be_ cruel; but the problem is, no matter how non-cruel you design your punishment to be, the person who is being punished will tend to *perceive* it as cruel if he hasn't yet repented of the behavior for which he is being punished.
Yes, historically there have been some punishments that were objectively very cruel. Making a man watch while you kill his children and then immediately gouging out his eyes so that's the last thing he saw with them, for example, is undeniably cruel. But that does not make it a good punishment. In fact, I don't think they did that to Zedekiah to punish _him_ (they were carting him off in chains afterward anyway), but to make a poignant example for others.
But you can take a decidedly non-cruel (even restorative) punishment, like having to do a couple of hundred hours of community service to repay society for the harm your vandalism has caused, and it can _feel_ cruel to the person being punished if he still doesn't want to admit, even to himself, that he did anything wrong. This is unavoidable, because the emotional reaction that the punished person is having is not to the specific mode of punishment but to the mere fact of being punished. And you can't maintain a functioning society without punishing crime in some manner or another.
> Nearly *all* currencies are speculative to some degree
Yes, but not to equal degree.
> I'm pretty shocked by the generally disparaging remarks regarding bitcoin.
Yeah? Try talking asking people how they feel about the peso or the naira or the real.
Of the (somewhere between 150 and 200) currencies in the world, there are really only half a dozen that get any serious respect, and except for the Euro (which inherited its position of respect mostly from the Deutsch Mark) they've all been essentially stable *and* influential on the world economic scene for more than half a century. Also, every single one of them is backed by at least one government that has been stable at least since the end of WWII.
The investment community regards new things generally as risky. This doesn't mean they can't be hot investment items (hedge funds and venture capitalists LOVE new things), but it does mean that investing in them is generally regarded as unsafe in isolation. (By "in isolation" I mean "not as part of a well-rounded investment portfolio".) When it comes to currencies, Bitcoin is very new, *and* it's not backed by the fiat of any major government.
So yeah, people aren't going to view Bitcoin as on part with the pound sterling and the US dollar and the Swiss franc. Not for a while, anyhow.
Actually, the net profit on gambling is always zero (taking all participants into account), which in the business world is not generally considered a high margin. Casinos, therefore, only have two ways to stay in business.
The main way is of course by stacking the odds to guarantee that everyone else (on average) comes out significantly on the negative side of things, so that despite the average being zero the casino itself makes a positive net profit. This is what they do for most games, including blackjack and roulette, and it really REALLY ought to be illegal. Incidentally, this is also what the state lotteries do. When you play any of these games, your expected net profit is negative.
For poker, however, the casinos don't gamble at all. They let _other_ people do all the gambling, and the casino just takes a percentage, which is the same no matter who wins or loses. Thus, they don't make their profit by gambling. They make their profit by providing a venue. So when you play poker, your expected net profit is theoretically zero (assuming that you and your opponents have equal skill and equal ability to cheat, which should theoretically hold true over the long term if you are average; of course, virtually everyone who plays the game does so because they believe they will be better than average). Poker is thus somewhat less exploitative, because everyone is on essentially equal footing. I'm still not interested in playing, and it doesn't _bother_ me that the thing is illegal, but I feel less strongly about it than I do about the more exploitative types of gambling where the odds are heavily stacked.
> ('I' stands for "It's National" not 'International')
Actually, the I in FBI stands for Investigation, and, relatedly, the I in CIA stands for Intelligence (by which they mean data acquisition, not the quality of being intelligent). And, indeed, the FBI continues to Investigate, and the CIA continues to gather information.
Admittedly, the CIA was originally conceived and chartered to acquire said "intelligence" regarding foreign (potential) enemies, complementary to the FBI's domestic bailiwick, and in practice this distinction has not always been maintained entirely rigorously. (Although, it is also arguable that the blurring of this line to some extent at least was inevitable in the real world.)
And yeah, I can't imagine they'll be very deeply impressed by this sophistry. "Our customers don't gamble with _money_ officer, heavens, no, that would be illegal, haha. No, we only allow our customers to bet poker chips. See? They're just little pieces of plastic, that's all. No real money is involved." What is it about replacing poker chips with bitcoins that will make this argument fly?
> He was of microsoft stock, which leads people > to believe it was malice causing this decision.
I'm not sure I buy that. Microsoft guys (especially near the top) tend to believe pretty strongly in their products. If he came from Microsoft, he probably actually thought Windows Phone would be great, both as a user experience and as a selling brand.
Okay, so he was wrong -- very objectively wrong by the latter criterion. Being wrong is not the same thing as being malicious.
Also, Symbian *was* already losing market share (as a percentage, because the other smartphone makers were experiencing significantly faster growth as a percentage), so it's not true that there wasn't any problem for the CEO to solve. His attempt at solving it was poorly conceived and went horribly awry, exacerbating the situation quite severely and putting the company in a much worse situation than they were already, but that's failure (severe failure, arguably), which again is not the same thing as malice.
I know what it is. It's like hacking into the Omni Consumer Products computer and reprogramming all the ED209s to stop anyone from getting into a particular building -- but you program them to do it without killing anyone.
> But wouldn't having a program do it for you be > like using mannequins to occupy wallstreet?
Even if you deploy the mannequins in and around the actual _doorway_ of the stock exchange (as opposed to camping out across the street or whatever), that's still only like a regular (non-distributed) denial of service attack.
A DDOS is more like stealing tens of thousands of mannequins from department stores all over the world and using them to block the door, except that still doesn't cover it, because people who want to get in can easily see what the problem is, and anyone who wants to bother to do so can pick up the mannequins and move them to clear a path.
> Everything is designed cheap and weak and falls apart quickly.
That tends to happen when most of the prospective customers can't accurately assess the quality of a product before buying it. Given two products, if they can't tell which one is better, most folks are generally going to buy the cheaper one. The company that insists on making a better but more expensive product has a harder time staying in business.
There are some exceptions. Notably, products that people buy _repeatedly_ are significantly less subject to this, because after buying it the first time people usually have some idea whether it's any good or not. However, that doesn't work if the old models are constantly discontinued in favor of new ones (e.g., anything electronic).
> Timed tests would only stress me out to the > point where I would probably code poorly due > to worrying about the clock.
That's one of the key reasons for using a timed test. Employers want to see who stresses out and panics when there's an impending deadline. On the job, there are going to be deadlines, and there are going to be customers calling and hounding the tech support people for a solution *right now*, and sometimes the tech support people are going to mention this fact to the programmers. When that stuff happens, the programmers don't automatically get to go home for the day because there was stress. They have to continue doing their jobs.
Admittedly, the test works best if the amount of time they give you is in fact well more than enough. That way they can weed out the people who panic needlessly at the drop of the hat, but everyone else can take their time and do a good job and not have to hurry.
> most good writers will turn spell check and > grammar check off, at least in my experience
I generally leave the red squiggleys turned on (except when working in a spreadsheet; they're just annoying in that context), because they do tend to help me to notice certain kinds of errors more quickly (mostly typos, but also certain kinds of spelling mistakes).
I certainly don't consider spellcheck to be authoritative, though. I frequently disagree with its judgments, in both directions. This very post contains two examples of words that it has underlined but which I consider correct.
> I don't believe that a speed programming will always identify the "better" programmers
You don't need or even necessarily want to identify the _fastest_ programmers. That's why you set a deadline that should be well more than enough time that they can not only solve the basic problem but also go over and edit their solution, comment it up, enhance it, and have time left over.
(For FizzBuzz, I'd probably give them fifteen minutes if they're interviewing for an application-developer position and might use a lower-level language like C. If they're applying for a network administrator position, I'd assume they're going to use a VHLL and give them five minutes, which is more than five times as long as they'd need to just solve the problem.)
One of the things you want to see is what they do with the extra time after they have basically working code. You also want to see who panics and hurries and writes bad code as soon as they get wind of a deadline. And the test administrator needs to be able to call it after a reasonable amount of time and send the stragglers away so he can move on to his other job duties. (Otherwise, there are people who will sit there for as long as you let them, even if it's six hours, racking their brain trying to come up with something they think they might have learned in school. At some point you have to put them out of their misery.)
> When I do my job in real life, I have time > to plan, research, and I can keep open > documentation for reference.
A good timed test provides enough time and resources to do a reasonable amount of that (where what amount is reasonable is dependent on the scope of the problem). The idea is not (or should not be) to find the fastest programmers. There are, however, several good reasons for *having* a time limit. One reason is so the test proctor doesn't have to sit there for hours and hours while some poor soul flogs his brain trying desperately to come up with things that he may or may not have known at some point but definitely cannot remember today. (Online or take-home tests can largely obviate this reason, but not every organization is comfortable with that approach.) Another reason is to goad people with certain tendencies (e.g., to panic under pressure, or to get in a hurry and rush to submit poor work the instant somebody mentions a deadline, even if there's actually plenty of time) into betraying those tendencies so you can take note of them.
For an extremely simple problem like FizzBuzz, fifteen minutes is a good deadline. Any decently competent programmer SHOULD be able to submit working code in under five minutes, even in an arcane fiddly low-level language (assembly language, C++, etc.), but you give them fifteen minutes so you can find out how different applicants use that extra time. Maybe one of the applicants will submit documentation along with his code. Perhaps another will generalize the problem and submit a version that takes command-line arguments to alter its behavior in various ways. Maybe one guy will submit code with a built-in i18n/l10n infrastructure. Now you have something to talk about in the interviews.
Obviously, if the problem is more complicated, the time limit should be larger.
> Well, I've never interviewed job candidates > and I have a hard job believing this.
I have done a set of interviews, but it's not relevant to this discussion. (We only interviewed three applicants out of, umm, a lot more than three; and I _wasn't_ involved with deciding which three to interview, which is really the relevant part here.) However, I *have* spoken with the person who have to look through the resumes we get and decide who is worth calling for a phone interview or not, so I think I can explain what you're missing.
> my brain has a very hard job accepting that > someone who does programming for their > livlihood could not solve this in their sleep.
You've made an implicit assumption, that people who are _applying_ for a job doing Thing X are necessarily people who do Thing X for a living. I can assure you that this is not the case. People just apply for every job listing they see, whether it's even vaguely relevant to their abilities or not.
When we posted a job for a Children's Librarian, we were very clear that the position required both a graduate degree in library science (or equivalent library work experience) *and* significant job experience working with children and teens. Most of the applicants had neither, and I got to hear my boss complaining about the quality of the applicants. (I found her rants rather amusing, mostly because they were novel to me; if I'd had to go through the whole pile with her, doubtless it would have gotten old.) Many of the applicants had no college education at all and had never worked in anything even vaguely resembling a library. One particular applicant that I remember my boss mentioning (albeit not by name) had no college education and prior work experience that peaked at entry-level data entry.
IMO, a useful weeding measure for any IT-related position, including programmers, is to only accept applications online. Lots of non-IT employers are doing this, but for IT positions it actually makes sense. Frankly, It'd be awfully tempting to build in an "attach your resume" form element that only accepts formats most non-IT people don't know anything about (TeX, nroff/groff, PostScript, DocBook, etc.)
Note that the reason for putting a time limit on the coding test isn't to measure speed. You give them plenty of time that anyone even vaguely confident should be able to complete it in the allotted time, because frankly you don't necessarily even want the fastest programmer; code quality is much more important than speed. (If the guy with the best quality code just happens to also be fastest, that's great; but that's not what you're testing for.) There are, however, several good reasons reason for making it timed. One reason is to panic people who are already nervous because they're underqualified, so they're less likely to pass by the skin of their teeth. Another reason is to find out if the applicant is prone to rush too much and submit bad code the instant somebody mentions a deadline, which is definitely a tendency you'd want to know about. But the main reason is so the person administering the test doesn't have to sit there forever while some poor soul with a mental block flogs his brain for hours desperately trying to remember things he may or may not have known but definitely cannot remember today.
Depends on the language. 3 minutes sounds about right for C.
Any Perl programmer who doesn't have a working solution in under a minute is deadwood. Given three minutes, he should revise the solution until it's elegant, easy to read, and maintainable (so that e.g. the numbers 3 and 5 can be replaced). In five minutes, it should take command-line arguments for all the different possible numbers to handle and what to say for them. And then he should look at you and say, "You know, I bet I just duplicated a CPAN module."
> Can you live eating only $16.50 per week's worth of groceries
For one person? Sure. It'll be a little tight if you want good nutritional balance, but it's very doable. (Umm, unless you live in a very large city or near the coast. Prices are higher in those places.)
In the short term, if all you need is enough calories, you can live on $5 worth of food a week. That'll be almost 100% carbs and maybe some oil to fry them in, but it'll keep you alive for a while. Eventually you'll start to come down with vitamin deficiencies, but that takes weeks or even months.
The other thing is, where I live, there are only two ways to lose weight (let alone starve to death): 1. Become a hermit and avoid all contact with people.
OR 2. Regularly turn down offers of free food, at the risk of offending people.
> Strange how the "athiest Europeans" treat their poor far > better than the "Christian" Americans.
Ethiopia has about as many Christians per capita as America does. (This wasn't always true, but times have changed.) And we treated the poor rather better when churches were handing out alms. It all went to pot when the government got involved. Now we actively penalize families that dare to actually have both parents, among other things.
Slashdot Mirror
> Hopefully they are just a recompile away from being fixed.
Have you ever tried to recompile a big pile of crusty, 25-year-old code that was only originally intended to be used for five years on one very specific platform and has not been recompiled since the last OS upgrade more than ten years ago?
It's not unusual to get tens of thousands of compile-time errors.
That's assuming nobody deleted the source code six years ago to make space on the old hard drive because the log file had never been rotated and all they knew was the hard drive was low on space and the source code was the only thing they were pretty sure they didn't need on a day-to-day basis.
> I'm mystified why it has to be a webcam, other than the joy of complexity.
It's an example of the X Y problem, documented thoroughly here:
http://www.perlmonks.org/?node_id=542341
Complexity has nothing to do with it. People see advertisements for uber-cheap webcams, know that webcams are designed to be hooked up to a computer, and think to themselves, "Maybe one of those things will solve my problem, and I'll only be out eight bucks!"
The question _should_ read, "Dad can't read anything less than a 36-point font, and his vision keeps getting worse, but he loves to read books. What's the cheapest way to solve my problem? Will a cheap webcam somehow solve this? Some other option?" But most folks don't have enough experience with tech support (or in some cases just plain don't think clearly enough) to know that they should word the question that way.
> fire the employee, keep the contractor.
No, no, no. You don't _fire_ the employee. In fact, give him a commendation for original thinking.
Then eliminate his current position by outsourcing it to the contractor, and reassign him into a newly created position in the Labor Outsourcing department (a subdivision of HR) -- on commission, so that in order to maintain his former salary level he has to outsource the job of one of his (now former) coworkers every week.
And, if you want to be really evil, feature a story about it on the front page of the employee newsletter.
That's actually not the problem.
The problem is that almost all currently available ebooks have DRM that ties them to one account and a small number of reader devices, in clear violation of the First Sale principle but backed by the anti-circumvention wording in the DMCA.
Currently the only way libraries can lend (non-free) ebooks _without_ lending the reader is through a contract with a company called Overdrive (who in turn have some kind of deal with the publishers). The way the Overdrive setup works has so many drawbacks and problems I won't even try to start listing them, but I'll summarize: it appears to have been deliberately set up so that library ebook lending will certainly fail to ever catch on in any significant way.
There have been rumors that at some point there may be a competitor to Overdrive, but I've yet to see anything concrete, and even if there were a competitor they'd still be bound by all same bizarre limitations the publishers have put in place. Competition in this market might improve some superficial aspects of the experience (e.g., the difficult-to-navigate Overdrive website), but the basic nature of the deal would be unchanged.
> My point was that maybe Americans aren't so Christian after all.
Oh. I agree with that.
> elegant, easy to read, and maintainable
> You mean rewrite it in another language?
Almost.
There are almost two entirely different Perl languages.
Perl code can be truly awful when it's written by people who are new to the language, have their thinking dominated by lower-level languages (notably C), or are just plain bad at writing code. I've seen some of that code. It's bad, no question about it. It makes my brain hurt. When I see it, I always get this urge to rewrite it in Perl.
(Okay, actually, there are _three_ Perl languages. Deliberately obfuscated Perl is even more difficult to read than badly written Perl, though it tends to be interesting and impressive and even fun to read, rather than just making you want to bang your head against a rock.)
> so it's a panic test, but you give them time enough to not panic?
You give them enough time so they don't _need_ to panic. Some people will still panic, even though there's plenty of time. You don't want to hire those people.
There are also additional things the test can uncover besides panic. Completely lying about having any ability to program at all is one.
That'll really only be a problem during the transitional period when only a couple of ISPs are doing NAT. I predict that within another decade virtually *all* ISPs will be doing NAT, and so websites and other services will just have to retool their thinking to take into account that most users are behind NAT.
> And how can the customers of the ISP run servers on their computers?
Most consumer ISPs officially don't allow that anyway. (They don't usually police it actively, unless your home server gets enough traffic to be noticeable. But the rule is on the books in most cases.) If you want to run a server, you're theoretically supposed to buy business-class service.
Honestly, I don't see a problem with ISPs levying a small surcharge (a few cents a month) for a public IPv4 address. Most people have no use for it. I personally do have a use for it (I like to be able to ssh into my home computer for work), but I'd pay a few cents extra for that, as long as the price is reasonable. Heck, up to a dollar a month would be reasonable IMO, simply because it's not that much money compared to what you're already paying for other services (chiefly, bandwidth and dubiously useful tech support).
And I *certainly* don't have a problem with ISPs only giving public IPv4 addresses to customers who actually ask for one. Take all the people who just want to get on Facebook and watch stupid videos on YouTube and put them behind NAT. They won't notice, and they won't care. If somebody tries to explain it to them and convince them that they've been wronged, their eyes will glaze over in boredom.
Actually, ICANN should cover its administrative costs by charging the regionals for IPv4 assignments in large blocks, instead of handing them out for free. A rate of one cent per allocated address would raise tens of millions of dollars each year. Then the regionals could cover *their* administrative costs by marking the price up slightly, and the large peered multinational ISPs who have the big blocks could mark them up just a little more, and by the time you filter down three more levels to the consumer we're still talking less than a dollar a year.
And that should be plenty to ensure that everyone has as many addresses as are actually needed, because they're not actually scarce. They only appear scarce because until now they've been handed out for free in unlimited quantity, and so *most* organizations are holding more public IPv4 addresses than they have any real use for; in many cases, multiple orders of magnitude more than they have any legitimate use for. I say, charge them a few cents per address and see whether they *really* need a Class A network for their three servers and two offices full of workstations.
> A punishment may be cruel (most are)
Punishment is, ideally, not supposed to actually _be_ cruel; but the problem is, no matter how non-cruel you design your punishment to be, the person who is being punished will tend to *perceive* it as cruel if he hasn't yet repented of the behavior for which he is being punished.
Yes, historically there have been some punishments that were objectively very cruel. Making a man watch while you kill his children and then immediately gouging out his eyes so that's the last thing he saw with them, for example, is undeniably cruel. But that does not make it a good punishment. In fact, I don't think they did that to Zedekiah to punish _him_ (they were carting him off in chains afterward anyway), but to make a poignant example for others.
But you can take a decidedly non-cruel (even restorative) punishment, like having to do a couple of hundred hours of community service to repay society for the harm your vandalism has caused, and it can _feel_ cruel to the person being punished if he still doesn't want to admit, even to himself, that he did anything wrong. This is unavoidable, because the emotional reaction that the punished person is having is not to the specific mode of punishment but to the mere fact of being punished. And you can't maintain a functioning society without punishing crime in some manner or another.
> Nearly *all* currencies are speculative to some degree
Yes, but not to equal degree.
> I'm pretty shocked by the generally disparaging remarks regarding bitcoin.
Yeah? Try talking asking people how they feel about the peso or the naira or the real.
Of the (somewhere between 150 and 200) currencies in the world, there are really only half a dozen that get any serious respect, and except for the Euro (which inherited its position of respect mostly from the Deutsch Mark) they've all been essentially stable *and* influential on the world economic scene for more than half a century. Also, every single one of them is backed by at least one government that has been stable at least since the end of WWII.
The investment community regards new things generally as risky. This doesn't mean they can't be hot investment items (hedge funds and venture capitalists LOVE new things), but it does mean that investing in them is generally regarded as unsafe in isolation. (By "in isolation" I mean "not as part of a well-rounded investment portfolio".) When it comes to currencies, Bitcoin is very new, *and* it's not backed by the fiat of any major government.
So yeah, people aren't going to view Bitcoin as on part with the pound sterling and the US dollar and the Swiss franc. Not for a while, anyhow.
> Gambling period runs a very high profit margin,
Actually, the net profit on gambling is always zero (taking all participants into account), which in the business world is not generally considered a high margin. Casinos, therefore, only have two ways to stay in business.
The main way is of course by stacking the odds to guarantee that everyone else (on average) comes out significantly on the negative side of things, so that despite the average being zero the casino itself makes a positive net profit. This is what they do for most games, including blackjack and roulette, and it really REALLY ought to be illegal. Incidentally, this is also what the state lotteries do. When you play any of these games, your expected net profit is negative.
For poker, however, the casinos don't gamble at all. They let _other_ people do all the gambling, and the casino just takes a percentage, which is the same no matter who wins or loses. Thus, they don't make their profit by gambling. They make their profit by providing a venue. So when you play poker, your expected net profit is theoretically zero (assuming that you and your opponents have equal skill and equal ability to cheat, which should theoretically hold true over the long term if you are average; of course, virtually everyone who plays the game does so because they believe they will be better than average). Poker is thus somewhat less exploitative, because everyone is on essentially equal footing. I'm still not interested in playing, and it doesn't _bother_ me that the thing is illegal, but I feel less strongly about it than I do about the more exploitative types of gambling where the odds are heavily stacked.
> ('I' stands for "It's National" not 'International')
Actually, the I in FBI stands for Investigation, and, relatedly, the I in CIA stands for Intelligence (by which they mean data acquisition, not the quality of being intelligent). And, indeed, the FBI continues to Investigate, and the CIA continues to gather information.
Admittedly, the CIA was originally conceived and chartered to acquire said "intelligence" regarding foreign (potential) enemies, complementary to the FBI's domestic bailiwick, and in practice this distinction has not always been maintained entirely rigorously. (Although, it is also arguable that the blurring of this line to some extent at least was inevitable in the real world.)
And yeah, I can't imagine they'll be very deeply impressed by this sophistry. "Our customers don't gamble with _money_ officer, heavens, no, that would be illegal, haha. No, we only allow our customers to bet poker chips. See? They're just little pieces of plastic, that's all. No real money is involved." What is it about replacing poker chips with bitcoins that will make this argument fly?
> He was of microsoft stock, which leads people
> to believe it was malice causing this decision.
I'm not sure I buy that. Microsoft guys (especially near the top) tend to believe pretty strongly in their products. If he came from Microsoft, he probably actually thought Windows Phone would be great, both as a user experience and as a selling brand.
Okay, so he was wrong -- very objectively wrong by the latter criterion. Being wrong is not the same thing as being malicious.
Also, Symbian *was* already losing market share (as a percentage, because the other smartphone makers were experiencing significantly faster growth as a percentage), so it's not true that there wasn't any problem for the CEO to solve. His attempt at solving it was poorly conceived and went horribly awry, exacerbating the situation quite severely and putting the company in a much worse situation than they were already, but that's failure (severe failure, arguably), which again is not the same thing as malice.
I know what it is. It's like hacking into the Omni Consumer Products computer and reprogramming all the ED209s to stop anyone from getting into a particular building -- but you program them to do it without killing anyone.
> But wouldn't having a program do it for you be
> like using mannequins to occupy wallstreet?
Even if you deploy the mannequins in and around the actual _doorway_ of the stock exchange (as opposed to camping out across the street or whatever), that's still only like a regular (non-distributed) denial of service attack.
A DDOS is more like stealing tens of thousands of mannequins from department stores all over the world and using them to block the door, except that still doesn't cover it, because people who want to get in can easily see what the problem is, and anyone who wants to bother to do so can pick up the mannequins and move them to clear a path.
You little life forms, you pretty little life forms, precious little life forms, where are you? Doo doo doot doot doot doot doo.
I just love scanning for life forms!
> Everything is designed cheap and weak and falls apart quickly.
That tends to happen when most of the prospective customers can't accurately assess the quality of a product before buying it. Given two products, if they can't tell which one is better, most folks are generally going to buy the cheaper one. The company that insists on making a better but more expensive product has a harder time staying in business.
There are some exceptions. Notably, products that people buy _repeatedly_ are significantly less subject to this, because after buying it the first time people usually have some idea whether it's any good or not. However, that doesn't work if the old models are constantly discontinued in favor of new ones (e.g., anything electronic).
> Timed tests would only stress me out to the
> point where I would probably code poorly due
> to worrying about the clock.
That's one of the key reasons for using a timed test. Employers want to see who stresses out and panics when there's an impending deadline. On the job, there are going to be deadlines, and there are going to be customers calling and hounding the tech support people for a solution *right now*, and sometimes the tech support people are going to mention this fact to the programmers. When that stuff happens, the programmers don't automatically get to go home for the day because there was stress. They have to continue doing their jobs.
Admittedly, the test works best if the amount of time they give you is in fact well more than enough. That way they can weed out the people who panic needlessly at the drop of the hat, but everyone else can take their time and do a good job and not have to hurry.
> most good writers will turn spell check and
> grammar check off, at least in my experience
I generally leave the red squiggleys turned on (except when working in a spreadsheet; they're just annoying in that context), because they do tend to help me to notice certain kinds of errors more quickly (mostly typos, but also certain kinds of spelling mistakes).
I certainly don't consider spellcheck to be authoritative, though. I frequently disagree with its judgments, in both directions. This very post contains two examples of words that it has underlined but which I consider correct.
> I don't believe that a speed programming will always identify the "better" programmers
.. 100;
You don't need or even necessarily want to identify the _fastest_ programmers. That's why you set a deadline that should be well more than enough time that they can not only solve the basic problem but also go over and edit their solution, comment it up, enhance it, and have time left over.
(For FizzBuzz, I'd probably give them fifteen minutes if they're interviewing for an application-developer position and might use a lower-level language like C. If they're applying for a network administrator position, I'd assume they're going to use a VHLL and give them five minutes, which is more than five times as long as they'd need to just solve the problem.)
One of the things you want to see is what they do with the extra time after they have basically working code. You also want to see who panics and hurries and writes bad code as soon as they get wind of a deadline. And the test administrator needs to be able to call it after a reasonable amount of time and send the stragglers away so he can move on to his other job duties. (Otherwise, there are people who will sit there for as long as you let them, even if it's six hours, racking their brain trying to come up with something they think they might have learned in school. At some point you have to put them out of their misery.)
OBTW, the quick Perl solution:
$\=$/; print join "\n", map {
$_%15 ? ($_%5 ? ($_ %3 ? $_ : "Fizz") : "Buzz") : "FizzBuzz";
} 1
> When I do my job in real life, I have time
> to plan, research, and I can keep open
> documentation for reference.
A good timed test provides enough time and resources to do a reasonable amount of that (where what amount is reasonable is dependent on the scope of the problem). The idea is not (or should not be) to find the fastest programmers. There are, however, several good reasons for *having* a time limit. One reason is so the test proctor doesn't have to sit there for hours and hours while some poor soul flogs his brain trying desperately to come up with things that he may or may not have known at some point but definitely cannot remember today. (Online or take-home tests can largely obviate this reason, but not every organization is comfortable with that approach.) Another reason is to goad people with certain tendencies (e.g., to panic under pressure, or to get in a hurry and rush to submit poor work the instant somebody mentions a deadline, even if there's actually plenty of time) into betraying those tendencies so you can take note of them.
For an extremely simple problem like FizzBuzz, fifteen minutes is a good deadline. Any decently competent programmer SHOULD be able to submit working code in under five minutes, even in an arcane fiddly low-level language (assembly language, C++, etc.), but you give them fifteen minutes so you can find out how different applicants use that extra time. Maybe one of the applicants will submit documentation along with his code. Perhaps another will generalize the problem and submit a version that takes command-line arguments to alter its behavior in various ways. Maybe one guy will submit code with a built-in i18n/l10n infrastructure. Now you have something to talk about in the interviews.
Obviously, if the problem is more complicated, the time limit should be larger.
> Well, I've never interviewed job candidates
> and I have a hard job believing this.
I have done a set of interviews, but it's not relevant to this discussion. (We only interviewed three applicants out of, umm, a lot more than three; and I _wasn't_ involved with deciding which three to interview, which is really the relevant part here.) However, I *have* spoken with the person who have to look through the resumes we get and decide who is worth calling for a phone interview or not, so I think I can explain what you're missing.
> my brain has a very hard job accepting that
> someone who does programming for their
> livlihood could not solve this in their sleep.
You've made an implicit assumption, that people who are _applying_ for a job doing Thing X are necessarily people who do Thing X for a living. I can assure you that this is not the case. People just apply for every job listing they see, whether it's even vaguely relevant to their abilities or not.
When we posted a job for a Children's Librarian, we were very clear that the position required both a graduate degree in library science (or equivalent library work experience) *and* significant job experience working with children and teens. Most of the applicants had neither, and I got to hear my boss complaining about the quality of the applicants. (I found her rants rather amusing, mostly because they were novel to me; if I'd had to go through the whole pile with her, doubtless it would have gotten old.) Many of the applicants had no college education at all and had never worked in anything even vaguely resembling a library. One particular applicant that I remember my boss mentioning (albeit not by name) had no college education and prior work experience that peaked at entry-level data entry.
IMO, a useful weeding measure for any IT-related position, including programmers, is to only accept applications online. Lots of non-IT employers are doing this, but for IT positions it actually makes sense. Frankly, It'd be awfully tempting to build in an "attach your resume" form element that only accepts formats most non-IT people don't know anything about (TeX, nroff/groff, PostScript, DocBook, etc.)
Note that the reason for putting a time limit on the coding test isn't to measure speed. You give them plenty of time that anyone even vaguely confident should be able to complete it in the allotted time, because frankly you don't necessarily even want the fastest programmer; code quality is much more important than speed. (If the guy with the best quality code just happens to also be fastest, that's great; but that's not what you're testing for.) There are, however, several good reasons reason for making it timed. One reason is to panic people who are already nervous because they're underqualified, so they're less likely to pass by the skin of their teeth. Another reason is to find out if the applicant is prone to rush too much and submit bad code the instant somebody mentions a deadline, which is definitely a tendency you'd want to know about. But the main reason is so the person administering the test doesn't have to sit there forever while some poor soul with a mental block flogs his brain for hours desperately trying to remember things he may or may not have known but definitely cannot remember today.
Depends on the language. 3 minutes sounds about right for C.
Any Perl programmer who doesn't have a working solution in under a minute is deadwood. Given three minutes, he should revise the solution until it's elegant, easy to read, and maintainable (so that e.g. the numbers 3 and 5 can be replaced). In five minutes, it should take command-line arguments for all the different possible numbers to handle and what to say for them. And then he should look at you and say, "You know, I bet I just duplicated a CPAN module."
> Can you live eating only $16.50 per week's worth of groceries
For one person? Sure. It'll be a little tight if you want good nutritional balance, but it's very doable. (Umm, unless you live in a very large city or near the coast. Prices are higher in those places.)
In the short term, if all you need is enough calories, you can live on $5 worth of food a week. That'll be almost 100% carbs and maybe some oil to fry them in, but it'll keep you alive for a while. Eventually you'll start to come down with vitamin deficiencies, but that takes weeks or even months.
The other thing is, where I live, there are only two ways to lose weight (let alone starve to death):
1. Become a hermit and avoid all contact with people.
OR
2. Regularly turn down offers of free food, at the risk of offending people.
> Strange how the "athiest Europeans" treat their poor far
> better than the "Christian" Americans.
Ethiopia has about as many Christians per capita as America does. (This wasn't always true, but times have changed.) And we treated the poor rather better when churches were handing out alms. It all went to pot when the government got involved. Now we actively penalize families that dare to actually have both parents, among other things.