I've also worn the hat of hiring highly skilled technical programmers. What I've found is that most of what 'good' programmers exhibit is self-motivated-determination to read on their own. People that read, not because they HAVE to get something done for work (and thus the bare minimum will suffice), but because they like to read technical manuals as if they were novels. They'll read it through, not because they're looking for a short-cut, or to get some nagging bug fixed, but because they want to dive-deep into some paradigm or language.

Well-read programmers sometimes comes from CIS degrees, usually NOT. Ironically most people I see coming out of universities are CRAP programmers. They go in thinking they're going to do this thing, but get overwhelmed quickly, become bare-minimalists in terms of understanding and (typically implementation), and resort to side-effect, poorly-documented, maximal-surprise code. Why? Because just like the all-nighter they pulled getting their project to work; it was passable.

English majors make great programmers, in my experience.. Presumably because they are people that can absorb a technical manual in a single night.

I've also found some electrical engineers too be good programmers (I happen to be among them). Mostly because they tend to attach problems from the bits up. They often have a very deep understanding of what a function is doing. It also means they have, by default, a richer math background - doing lots of math/equation proofs is useful when writing logic-functions.

So if you're past the college years and are trying to prove yourself. Do a lot of deep-dives of open-source projects.. Convince yourself that they work (e.g. critically analyze the code to understand the decisions made, as if you were the one making those decisions). Make sure you become familiar with a tool-chain (gpp -> gcc -> asm -> objcopy -> ln -> kernel-loader). Convince yourself that lisp is a great language (this will require every ounce of logical-strength that you can muster). Learn small-talk (the parent of most paradigms these days). Learn C++ (so you can see what everybody is trying to implement without actually implementing). Develop a VERY good understanding of C - (learning how everything is a symbol) - try and correlate obdump -x and 'nm' against C functions.. Learn how to make a shared library (either windows DLL or linux .so or Mac OSX dynlib). Delve into the format/layout of ELF. Learn the significance of the various segment-types (this generally applys to all OSs). Learn an ASM if you can.. Start by running
gcc -S helloworld.c
and
gcc -S -m64 helloworld.c
for the 64bit equivalents.. Make sure to put lots of function-calls, floating-point and OS calls.. Learn what the assembly is doing.. wikipedia ANYTHING you don't understand.

Learn a good editor.. Visual Studio, Eclipse/IntelliJ, X-code, kdevelop, codeblocks. Learn at least 64 short-cuts in two of them. Get familiar with thin editors (notepad++, vim, kate).

LEARN TCP. Google it.. Use perl, python, ruby or Java to write your own client / server in both TCP and UDP if you can. If you're up to it, try writting it in C or C++ + boost or Visual Studio.

LEARN the HTTP protocol (almost impossible to be useful these days without it). Use 'nc' 'curl' 'wget' 'telnet' interchangably to interact with an HTTP service.

Learn XML.. At least the DTD, but to really do well, learn XSDs.. Use javascript's DOM to muck with it to start.. But you'll probably need to learn a C/C++/Java/.NET's perferred APIs. It's hard to NOT have to parse XML in most paid-applications.

Learn UML. Read a good book on design patterns; eventually you'll think in UML for classes and DB entities; but you'll also need to think in terms of it for collaboration diagrams, sequence-diagrams etc.. (lots of free [online] tools.. creately, lucid-charts, argouml). Learn to white-board as if you were Italian. This goes over GREAT in interviews.

Learn SQL.. It's not going anywhere, I promise. Use postgres + pgadmin or mysql + phpmyadmin. Learn what RDBMS is.. What ACID is.. What the CAP theorem is. Try the free Oracle if you have an afternoon to totally lose; but it's probably useful in job-hunting.

Read up on NoSQL solutions.

When creating your resume (after 2 hours of doing all this), make sure to be HONEST in your skill levels in all of the above.. Don't JUST list that you know mysql,postgres,oracle,MS SQL. List mysql [expert], postgres [seasoned], oracle [exposed to], MS SQL [novice]. This avoids wasting people's time, and prevents dissapointments in the interview that would otherwise have been managed expectations leading up to a (yeah, he'll need some ramp-up-time, but I think we have work for him).

Depends what's meant by 'putting in separate folder'. Can an email have exactly one parent? Then what happens when you have 50 folders, each with 300 unread items. Is this more or less organized?

My preference is to have 100% of emails show up in inbox - but be auto-tagged. This is better than traditional folders because there is more than one parent.

todo, Reference, todelete, asap, projX, companyY, contactCategoryZ, personal, mailinglist, mailinglistX, etc

For each new email, I set up a rule to tag all similar emails (90% are todel). BUT, because they always show up to INBOX, I have a half second glance to decide if that email needed TODO/Reference, or if I don't want it todelete for some reason.

Searching on tags is superior to remembering keywords, because you can navigate the tags (just like folders). And depending on your email tool, you can mix and match "(tags:foo or tags:bar) subject:sales".

Right, but what is the basis for the paranoia. I am highly skeptical (even of a geek community) of properly directing that paranoia to non tin-foil-hat conspiracies.
1) Theft follows the money and the naive (e.g. major banks, major places with credit cards, and people/groups susceptible to social engineering attacks)
2) net-Stalking generally is done by major govs/institutions that make wide-area attacks with non-targetted victims, or petty people with no servers from which to reliably cause a reasonably cautious netizen to worry.
3) Ad-tracking / Ad-metric-gathering allows vendors to.. Well, produce more targetted ads. I never understood the visceral hatred of double-click. Though I share the frustration with ad providers that steal my cursor with CSS popup DIVs or flash.
4) Porn sites presumably can detect repeat non-paying visitors and restrict content (big shocker there).

I understand the notion of a condom-mode web browsing (no cookies, no cache, no passwords), and I can see the frustration with the web essentially being broken in that mode; but honestly. Session cookies are much more elegant than embedded tokens in paths; as they are perma-linkable. And being a personal hater of 'apps' when a stateful website is just as functional (and almost by definition, more portable), I find it difficult to swallow a demand that HTTP remain stateless.

"Don't assume that any cookies you set will ever be sent back."

Don't do a lot of online banking do you? Hello 1993 called and wants it's gopher back.

"6) Delete all accounts numbered 2,000,000+. Remove signup. Invite only"

Heck, why not start at, I don't know, say 1,000,000 Mr 1.05 ;)

Though I do get a sense of "get off my lawn, when I was young, commenters respected their elders" :) I remember from when slashdot started, people were ALWAYS complaining about poor comment quality.. But sorry guys.. I don't see it.. If there is ONE good comment in a comment stream (above level 3, let's say), and I can quick-read through 30 comments, I call it a win.. I've learned something new. If I didn't, I wouldn't waste the, oh, I don't know, 8 minutes a day it took to read those 30 comments. A little more productive than day-time-TV, I'd say.

haha! So Muslims and Christians should probably re-read it then, because NOBODY that I know actually expouses that.. Here's what a classic Muslim would say:
1) Accept Allah as the one true god
2) Accept the profit Mohammed (may peace be apon him)

Here is what a modern Christian would say
1) Jesus is God
2) Jesus is God's son [and please ignore my apparent stupidity]
3) Adam and Eve ate the forbidden fruit so we're condemned to eternal damnation - as unfixable sinners.
4) Accept Jesus as your personal savior (your sacrificial lamb to quelll your original sin), or perish in a lake of eternal hell fire.

There's no mention of love, or neighbors.. Just God and your acceptance of Salvation from an apparently 6,000 year old forbidden fruit..

All the parables are for naught, because... We should NOT help the poor, because they'll just spend it on sinful things.. We should TRY and enrich ourselves (because a passage in the old testiment referred to as the Jabez passage) says if we ask God to enrich our life (so that we may exault his), then God will do so. We SHOULD conquer other Infadel nations and spread the 'good word' (because some prick non-Jew named Paul started the trend in the new testiment). We SHOULD ready the end-times by facilitating ancient prophecy in Israel (even though for 2,000 years nobody has been even close to a fullfilment, and mathmatically everybody has their own calculation based on BS numerology). We should NOT give up our wealth, because it's better spent looking fabulous in a papal gem-studded-robe or televangelist palace - praise be to JeSUS. We should NOT love they neighbor if they are: jewish, muslim, homosexual, left-handed, speak in a different language, seem animal-like and thus not derived from Adam (e.g. black), reject Jesus openly, have some contractable disease (they're being punished by God of course), or have a tiny nuance difference in the view of how to worship rules 1 .. 4, etc. We should NOT pay taxes because Ceaser kills babys (and not enough grown men).

But, you are technically correct, If modern Christians did actually have a prioritized critical analysis skill of any sort (as opposed to meme-repetition), then it's pretty clear that the 'greatest commandments' involved love. And the parables did center around forgiveness, kindness, charity, non-violence, social-aclimation (e.g. paying taxes, and getting along with your arch-enemies across the river). You know, the crap godless Hippies and Athiests expouse.. Go figure.

Though there was some crazy period mysticism crap in there.. The whole fake-rise-from-the-dead ritual (Lazereanism), baptism ritual (zorastrianism), placebo healing rituals (gee, that would be most religious, except maybe Judaism), Jewish rituals of course. Still, most people think Jesus invented / originated those rituals (and some crazily think they were 'magic'/divine because somebody wrote about it in a biography). Why would a biography lie? If they were true, and if God wanted the 'good news' to be heard, then he wouldn't let people lie about it, right? Which is why thousands of books had to be burned prior to the canonicalization of the modern New Testiment in 300AD I guess. :) But the logic works if you squint REALLY hard.

My understanding of quarks is that they were essentially of complex mass - which is why they can't exist individually, but must do so in some complementary pair or tripplet. It's the same as the root of a cube.. There are three solutions and two NEED to be conjugate pairs (e.g. imaginary).

I am suspicious of such numbers. You need to pick an application and run it on two machines for comparison. Number of active threads is independent of the number of CPUs - and while this means overhead in context switching into and out-of CPUs, if the reason they're stalled is memory throughput or disk IO, then CPU context switching is irrelevant.. And guess what, the memory throughput has little to do with the CPU.. Namely you can construct a NUMA motherboard where each CPU has localized RAM (and thus unaffected by threads in other zones).

The main reason I call BS on 2, 4 or 16 threads per core is that this explicitly only allows a single actively running thread; it merely means that IF you can do NON RAM work in the other 15 threads, then when thread-1 stalls you can get useful work done by quickly switching without OS interaction. But that's a big IF.

"Essentially, this is about as efficient as you can get"
I don't know about that. alpha/AMD added the 'mesh' CPU network, where you talked to routed neighbors for memory/BUS access, and thus not every CPU needs to spin it's transistors on cache operations. I don't know how advanced that got, but there's no reason that N,S,E,W cache controller nodes can't determine the scope of dissemination of cache-reads, and thereby localize snoop and lock-cache-line calls. Compre-and-set can be implemented IN the cache-line. You've got an address-line and a data-line. Why not add a cas bit on the routed bus and say 'Here's the old data, and it's address, and set the cas bit; then on the next clock, the data line will contain the new data. The mem-controler reponds with a read-complete operation or invalid'. You already have comparison logic for the address lines in their fully-associative cache logic; no reason you can't implement CAS there too.

So now you completely avoid a BUS-lock.. The cache atomicly (within a cache-clock-tick) owns the data.

I'm not a fan of mutex-spin-locks, because most algorithms that are fast enough to warrent a context-switch-free operation generally can use an optimistic-locking algorithm. Thus, I believe OS ctx switches or CPU-oriented thread-swap operations are field (e.g. some type of yield operation). But there are integer or pair-of-integer algorithms that can make heavy use of such CAS operations. And generally, the first step of a mutex is such a CAS.

If you were crazy enough to want to use semaphores instead of mutex's (hopefully because you actually want a constrained resource count, and not because you just prefer semaphores), then this CPU operation wouldn't make sense.. I doubt you want a full-on adder in the cache-controller (though I suppose that's possible too). Namely instead of 'lock; xadd [m1], 1'. You'd have "st_add [m1], 1" where the cache-controller is required to implement read, add, re-write (atomicly) instead of having the CPU do it.

Next is the furthered notion of topological CPU configurations.. Namely, pin thread-5 to CPU-2 then pin thread-6 t CPU-3 (which is adjacent), and the OS tells both CPUs that a shared memory segment (including mutex regions) is ONLY available to those two CPUs. And thus you can pass synchronous control signals between them.. Again, special instructions are required.. But now you can use 'barrier' instructions.. Similar to an idle spin loop (wait until barrier signal arrives from co-processor indicating the pipeline of work has new data. But this now starts competing with GPUs and CELL processors.

I'm sure there are other possible operations, such as direct register to remote-CPU register transfer operations.. Similar in principle to the SUN SPARC register window, you can have an in/out suite of registers where instead of function-call communication, we're facilitating asynchronous co-processors pipeline communication operations.

There are code paths that make sense to implement these sort of pipeline co-process architectures. Any place a 'spawn task' operation happens, that can be optimized in assembly + OS as a co-process pair. You would need some specialized C function APIs:

Future f = DispatchTask(data_structure); // co-process/ co-thread dispatch ....
mytype result = f.get(); // co-process barrier (CPU might context switch to peer thread)

"DB are generally IO bound: they must provide guarantee that committed data were safely written to disk. This is where the most of DB's performance is wasted - waiting for the disk to do its job.".
Sometimes. When they are IO bound, then yes, locks are of trivial importance. But DBs generally also serve as massive coherent caches and lock-managers. And those caching operations are VERY susceptible to critical-region code. Namely MySQL INNODB had an inverse performance characteristic with the number of CPUs for a long while. Further, recently, it was shown that by skipping the SQL layer of MySQL-INNODB and using simple direct HTTP calls into the storage layer, performance was improved measureably.

There's no accounting for bad code (which is most likely the case with MySQL optimizations), but I definitely feel that the programming world is solely inadequately prepared for multi-threaded programming.

Basically we need to focus on lock-free algorithms (or wait-free, or read-lock-free as appropriate). They should focus on optimisitic locks instead of pessimistic locks. Use compare-and-set operations/spin-loops. Use stack / context-variables instead of globals, etc. But most people just think in their 1960s sequential style and go; oh, two guys touch this so let me throw in a mutex. Then you find when you double the CPU count (or even machine count) that the system degrades miserably.