Slashdot videos: Now with more Slashdot!

You're confusing cause with effect. Programmer wages aren't high in the Silicon Valley because of having a lot of programmers. There are a lot of programmers because the wages are so high that CS majors come here in droves after college.

The reason the wages are so high here is because of basic supply and demand at work. Silicon Valley has only about a 3.6% unemployment rate among programmers, and a lot of the unemployed either want to be unemployed or are unemployed because their specific skills aren't in high demand. Programmers may be common in the Silicon Valley, but the demand in the Silicon Valley far exceeds the number of qualified programmers who are available and looking for jobs. Thus, the entire market is a zero-sum game, and the high wages are a result of the need to buy people away from other companies.

As a result, any sudden increase in the number of programmers drives down salaries for new hires, and fairly dramatically at that. For proof, you need only look at what happened to programmer salaries outside the Bay Area during the dot-com crash, when droves of people suddenly were looking for more affordable places to live. In some areas, salaries for programmers dropped almost in half because of that exodus.

Is it realistic to believe that there will ever be enough programmers to satisfy the Silicon Valley's voracious appetite? Hard to say. But that's a separate question.

Yes, it is pretty silly for them to expect the government to educate people. It is not like an educated population is some kind of public good.

Well, it is a benefit to the public as a whole to a large degree, but there is a dark side, too. The main reason that companies want to increase enrollment in CS is to get a larger pool of people to draw from so that they won't have to pay employees as much.

I'd also tell her about your illness, and tell her what you tried, just in case it is congenital. The more detail, the better. It might save her life someday.

Also, if you haven't already, you should check to see if you qualify for any of the immunotherapy trials going on. Search here if you haven't already.

Fair enough. In cities with a sufficiently large pool of lawyers, randomly select the judges for each case from the pool of lawyers who specialize in that particular area of law. The goal of randomization isn't to eliminate specialization, but rather to take most of the politics out of the process by ensuring that all qualified individuals have an equal chance of taking a particular case.

My proposal is rotating judgeship. Everyone who successfully passes the bar exam is put in a pool until they choose to retire (at which point they can no longer practice unless they rejoin the pool). Then the judge for a given case is chosen randomly out of everyone in the pool within a 25-mile radius, with an automatic redraw if the chosen judge is one of the attorneys involved in the case.

For the DA, have five of them in any given district working as equals, and require them to vote on whether to prosecute each case (i.e. if only one or two prosecutors want to "get that guy", the case doesn't move forward). From there, they can fight amongst themselves about who actually does the prosecution. Then require all the lawyers within a voting district to caucus once every two years to choose those five DAs from among their ranks. Enforce a strict two-term limit to ensure that people don't make a career out of being the DA.

Although you're correct about traps vs. interrupts, the reason I use the term "trap" is because the word "interrupt" is a much broader term. Most of the time, when we talk about interrupts, we're talking about some hardware device telling the CPU that it needs attention, rather than an application doing so. Thus, if you ask what an interrupt is, you'll probably get a very different answer from most programmers.

I'd expect anybody who has taken a basic OS course to have at least heard of traps and understand the basic concept at a high level—an application executes an instruction whose purpose is to tell the operating system to jump into the kernel and do something special. Anything beyond that is gravy. But if they stare at you looking confused, offer, "or you might also know it as an interrupt instruction".

As for JE... yes, you could ostensibly write code without ever checking to see if two values are equal, but it would likely involve very contrived, inefficient code (e.g. subtract the value, branch if zero, add it back). And if you don't recognize that jump or branch instructions typically start with J or B, and that EQ likely means "equal", chances are very good that you've never written a single line of assembly language for any major CPU architecture—not ARM, not MIPS, not i386/x86-64, not PPC, not even 6502.

Yes, there are exceptions to every rule. In fact, the ones I suggested are full of exceptions. They're not really meant to exclude people, but rather to counter the systemic bias that I've seen from lots of companies who tend to mostly hire new college grads from bigger schools, and then wonder why so many of them can't code their way out of a paper bag. :-)

And of course, as in any other field, the longer you've been out in the workforce, the less effect your college experience has on your abilities, or at least one would hope that this is the case. Otherwise, that person isn't learning, and will eventually hit a roadblock where he or she can't progress to a new job because nobody is hiring people to do what that person has always done.

You can only do it in one request if you provide a UI to let the user check a bunch of items and then tell it to delete everything that's checked. Frankly, I find that sort of UI design to be undesirable because it separates the action too far from what is being acted upon, but that's just my personal view.

I have worked with many CS guys would couldn't code for shit because they never bothered to actually learn the language they're coding in, because according to them it's all just syntax. And the ones with the masters in CS are some of the worst developers I've seen.

Apparently, you've never read code written by people with masters' degrees in physics.... Talk about people not taking the time to learn the language....

The thing is, a master's degree in CS doesn't necessarily give you any real-world coding experience, and doesn't necessarily give you any real-world engineering experience. And there's a wide range of undergrad degrees backing that master's degree. Remember that a master's degree usually gives you a lot of theoretical knowledge, and a lot less practical knowledge. Most of a candidate's practical experience is likely to come from his or her undergraduate degree.

Want to find someone who really understands how to write software? Hire someone whose undergrad degree came from a smaller college (which is more likely to be closer to a trade school, with less theory and more practice), and ideally someone whose background is in something other than Java. Why? Java hides way too much of how a computer works, so Java programmers often lack enough understanding of what's going on under the hood to write good code.

In your interview process, ask obscure low-level architecture questions, like "What is a trap?" or "What does the BEQ/JEQ/JE opcode do?" These questions will rule out anybody who hasn't ever worked with any form of assembly language. From there, try to ask questions about their learning style to try to figure out if they are self-teaching (which tends to be a sign of a good programmer, because it enables someone to rapidly adapt to working on code that he or she didn't write).

Or find somebody with a master's degree whose undergrad degree came from a small school, and just assume that the odds are good that he or she was serious enough about programming to figure it out on his or her own.

I was talking about:

f(result==OhShit) {foo.unwind(); foo.cleanup(); foo.bar(); foo.close(); foo.dispose(); foo=null;}

Which is okay as long as it happens only once, but if you end up with several returns, and you need to add foo.releaseNetworkConnections() to all of them, odds are good that you'll miss one, and now you have a leak (at least).

Your first approach is generally a very bad idea. The more copies you make of a block of code, the higher the probability that you'll miss one of them when you later have to modify that block of code. If you have more than about two statements that have to appear before every return statement, your odds of introducing bugs goes through the roof.

Functions are an acceptable way to handle complex cleanup, but they don't really buy you anything over a goto, and if you're cleaning up a lot of variables, the argument list can become unmanageable.

That's why the "goto fail" pattern is so common in kernel programming, where a single bug can be catastrophic.

A better example:

char *dosomething() {
char *tempvar = malloc(...);
char *tempvar2 = malloc(...);

do something...

if (some error occurs) {
goto fail;
}

do something else...

if (some error occurs) {
goto fail;
}
...
free(tempvar2);
return tempvar;

fail:
if (tempvar) free(tempvar);
if (tempvar2) free(tempvar2);

return NULL;
}

Basically, it works well when you have a significant amount of cleanup to do upon failure, because the alternative is writing half a dozen free/delete/release/CFRelease calls right before every return statement.

Wide spread, end to end encryption would need to be implemented.

Nice in theory. Not so much in practice. With crypto, the devil's in the details. Here are just a few of the hard problems:

• Initial key exchange: How do you know whether that public key really belongs to the person you want to talk to? Physical exchange of a key? Key signature? Web of trust? Or just trust a service provider and hope for the best?
• Key updates: Periodically, you'll need to upgrade to a longer key and a new cert. How do things work during that interim period?
• Expired certs: At some point, those keys are going to be crackable. How long do you trust the expired certs for messages that have already been received?
• Key revocation: How do handle it in a way that ensures that it can't be readily blocked without also blocking the main data channel?
• Key revocation: How do you handle the inevitable situation where someone's device dies and they don't have a copy of the original key at all?
• Key storage: What sort of protection is in place to minimize the risk of the key leaking?
• New devices: How do you migrate the key to new devices securely?
• Ability to audit: How do you know that things really are being encrypted end-to-end? What about after the software gets updated?

If it were easy to do it properly, end-to-end crypto would be ubiquitous.

All shot from almost exactly the same angle, which makes them a terrible source of reference data. To do facial recognition well, you need multiple shots of each person, taken from multiple angles... like Facebook already has.

Curiously, Radio Shack in Sunnyvale was basically empty a few days ago except for the electronic components section, which is all I care about anyway. Here's hoping they co-brand it with Sprint and keep that back section stocked as-is. :-)