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. :-)

Fry's has had some of that random junk down the center aisle up here for many years. I haven't seen much change in their product offerings otherwise except for products moving around constantly, lack of magazines (because print is dead), and lack of greeting cards (because I guess everybody buys them at Target).

Oh, and they reduced their DVD/Blu-Ray/CD offerings to make room for more games, because that's what people apparently are buying.

Designing an API properly does take a long time, but they had to do that anyway for first-party apps, whether they made it public or not. To be fair, the bar is a little higher for a public API because of the need for maintainability, but it isn't that much higher, particularly given that the non-UI parts of the SDK were mostly shared with OS X, which was already a public API.

I seriously considered starting that post by saying that Nokia committed suicide by not picking an OS and sticking with it, but even with all their problems, they might have survived relatively unscathed had it not been for the glut of cheap Android phones washing the ground out from under their foundation. :-)