Likewise. Tixati is like uTorrent was when I first started using it - small, lightweight, simple, fast.

Not the right applicants. For most positions (except the ones where you're a very small cog in a very large wheel) you have to be able to deal with people too.There was one question in a recent interview that my wife conducted, to which the applicant replied "I can't answer that without knowing more about the requirements." Which was exactly the right answer. He got the job.

This is where we as techies have to step up and not let the clueless take charge. This isn't something I've found a general solution for - if we focus on actually doing our jobs, then that keeps us busy while "non-technical" people sit around with nothing to do. They then have time to do all of the networking, socializing, presence-building etc. that basically lets them schmooze their way into upper management.

I don't really have anything to fix that, other than the observation that corporate culture starts from the top. If a company is built and run by an engineer then they'll respect people who actually get the job done. If it's run by people who got there by schmoozing then they'll only respect people who schmooze.

In that case yep, I'm totally with you. No matter their specialization, a software developer should be familiar with basic concepts in encryption, networking, algorithms, hardware architecture etc. Nothing in-depth maybe, but they should have some idea what's going on. It's like the way a doctor might specialize in oncology but should still be able to identify a ventricle or an Achilles tendon.

You (as in, the person asking the genie) are trying to find a way to describe the skills to be precise
Without having the skills to be precise
Or the skills to recognize whether something is precise
Or the skills to recognize whether someone is being precise
And yet still somehow assuming that it's easy to be precise.

He didn't even say anything about "build an app which sends a file using PKI". He just said "how would I send a file?" All the applicant had to do was answer "well I'd give you my public key and then use PGP to encrypt the email." Is the general concepts of public key infrastructure not basic required reading these days? It's no more unreasonable than asking "I want to send a stream of bytes to another computer on the internet, how would I do that?" and expecting an answer describing TCP sockets.

Really? You should at least know the basics of public key encryption if you want to work in computers. It's as much a cornerstone of modern information tech as the OSI stack or the filesystem.

Genuine answer is "most of them", but only because virtually everyone is terrible at software development. Note that even terrible developers will get there eventually and if you're developing simple software they may still be your best bet. You only need excellent software developers (which implies strong analytical and creative skills) if you're working on something interesting. If you're grinding out simple business logic you are probably better off with mediocre developers because they won't get bored. A scalpel is sharper than a bread knife, but it's not very useful for slicing bread.

In my career, out of the ~50 I've worked directly with, I've worked with maybe three developers that I'd class as excellent. A few that were "good" for various definitions of that word. The rest were marginal at best, but they still got things done after a fashion.

There's a huge glut of engineers who think they're good. Draw your own conclusions.

Likewise, the novel The Curious Incident of the Dog in the Night-time is told from the point of view of a 15-year-old boy with Autism-spectrum traits (although the author does not share those traits, so it's not really "an insider's POV").

I prefer:
1. Rationalize with your enemy
2. Maximizing efficiency will not save us
3. There's something beyond empathy
4. The data should be a guideline in war
5. Get your reasoning
6. Belief and seeing are both oneself
7. Be prepared to be often wrong
8. Never say reexamine your reasoning
9. Naturally, you may have to engage in evil
10. You can't change human proportionality

Exceptions make it easy to handle fault conditions badly, but no easier (and arguably harder) to handle fault conditions correctly. I was just reading this rant on Old New Thing today about this very subject. If nothing else, the amount of debate on "how to do this easy thing properly" should suggest that exceptions aren't a silver bullet.

I've seen the structure you're describing in a DirectX tutorial (admittedly, back in DX3):

if (!doFirstStage()) goto cleanup;
if (!doSecondStage()) goto cleanup;
...
if (!doTenthStage()) goto cleanup;
printf("woohoo!\n");
return true;

cleanup:
cleanupTenthStage();
cleanupNinthStage();
...
cleanupFirstStage();
printf("bugger");
return false;

It was actually advised as best practice for initializing the stack of COM objects required to get DX up and running. It's certainly cleaner than:

if (!doFirstStage()) {
cleanupFirstStage();
return;
}

if (!doSecondStage()) {
cleanupSecondStage();
cleanupFirstStage();
return;
}
...
if (!doTenthStage()) {
cleanupTenthStage();
cleanupNinthStage();
// ...
return;
}

The RAII pattern makes this a lot simpler (at least in OO languages), but if you're sticking with C then this "goto failed;" is simpler and probably cleaner.

You really think none of your jokes have ever offended an entire group? Typical stupid AC. :P

Not a closed system. Even those little sealed terrariums will die if you leave 'em in the dark for long enough.