I don't think the NSA sharing the data they collect is the problem. The
real problem lies in what data the NSA--as a government agency with
special powers--collects. Could making some of this more public be the
thing that finally leads to a change in the NSA's blanket surveillance
over citizens? (Actually, I'm not that hopeful.)

> I've heard stories from a technical director at a major American firm where they'd reject PHDs
> simply because they were worried they'd leave for higher paying jobs elsewhere.

Employers who think this way will ultimately hire the employees they deserve.

Pay is not the only thing that attracts a person to a job (or keeps them there). A person leaves
for a *better* job, which may or may not mean it offers higher pay.

They must use middle-out compression.

I predict that NONE of those surveyed will say "to be able to make phone calls"
either.

I think that security is something people don't think about very much, but they
also buy the phone with the assumption that *surely* it would be made secure,
("they would be fools sell it to millions of people if it were not secure").

And, to a reasonable extent they *are* made secure. But securing a device is a
process, not a one-time event. It is an ever-escalating back and forth between
having all known holes plugged and an intruder finding the next one (which is
presumably harder to find).

If you are a high quality developer, you want your code to be correct.
This means you are not threatened by a review finding bugs--you
*want* a review, so anything you missed gets found. The code you
check in under your name is something to take pride in, and you
don't want your commit to be the one with a bug in it.

That being said, my experience has been that most people don't
know how (or have the patience) to do a good, thorough review.
Time gets spent commenting (and arguing) about superficial things
rather than understanding and verifying meaning embedded in the
code under review.

It's unfortunate, because time spent doing a good code review is
*much* more productive than the aggregate time spent (by customers,
support, and ultimately developers) on bugs found in the field. The
cost of bugs rises incredibly quickly the later they are found.

So code review is very important, but (like code) if it's not done
well it's just not that valuable, and may do more harm than good.

The only problem with this is that the recipient
gets stuck with a printer whose ink is expensive.
The Salvation Army is in no better position to use
an inkless printer than you are.

If people are not keeping the comments in synch with
the code, *that* is the maintainability issue. Bad
comments (not concise, not informative, not clear)
may be harder to keep up-to-date, but that's not any
different from poorly-written code being hard to
understand or update.

Comments should be viewed as an intrinsic part of the
code--and if you change the machine-oriented part you
better be sure that the human-oriented part is updated
to reflect the change. And if necessary, improve the
comments while you're at it.