Just to point at one example: Elementary. The commercial volume is consistently MUCH higher than the show volume, which itself fluctuates enough during the show to make it annoying to watch. If the FCC really wanted results, they could just have some automated application "listening" to programs, and fining broadcasters automatically, rather than judging effectiveness based on quantity of people with enough time to waste to go through their complaint process. Based on how easy that is, I'd say they have no desire to actually help anyone.

I agree with the list, generally-speaking.

I would expand on the designing things point: it's not just matching requirements with implementation, but also designing something which will still work 10 years and 20+ design and technology iterations from now. It's designing something to anticipate future changes, and code in flexibility where appropriate. It's making something which doesn't just perform the function, but doesn't have subtle flaws which will cause very hard to diagnose issues down the road. It's building code which will still be maintainable, even after various future iterations. The ability to design code properly is what differentiates between a "normal" developer, and and extraordinary one.

IMHO, anyway.

No worries, the Kinect only needs to be connected and powered on for the system to function, you can "turn it off" (in software), and it won't do "anything" [that you can see]. Moreover, the XBone doesn't need an always-on internet connection, so even if it were watching your every move and listening to you 24/7, it wouldn't be uploading that information until the next time you connected. And even if it were secretly doing that, Microsoft wouldn't be sharing that data with the government unless legally required to. And even if we were sharing the data voluntarily through a well-documented Prism access tunnel, you have nothing to worry about unless you are a terrorist. And you're not a terrorist, are you?

The system could be fixed trivially, if people cared to do so. For example, add a provision to the law which allows an affirmative defense of independent discovery; after all, an innovation worthy of a patent is supposed to be innovative enough that other people cannot just stumble upon it through normal evolutionary work. That would put the onus on the patent holder to prove that the patent information was accessed by the accused-infringer during development, which would make it substantially harder for patent trolls to exist (that is, it's much easier to assert that you didn't see the patented item in the Patent Office publications, than in a competitor's widely distributed implementation).

The fact that it's not fixed points to malfeasance on the part of Congress, as much as private individuals taking advantage of the system.

(I work in a small but successful company as the lead developer.)

To be honest, most companies produce fairly bad software, fairly inefficiently, and you really don't need really good developers to do that. You can make a good amount of money just supporting existing products someone wrote a while ago, adding small improvements for marketing purposes, and/or writing something which is not particularly complicated, but profitable (see: 95% of apps for mobile, internal enterprise apps/scripts, template-based web sites, etc.).

You need "rock star" developers for only a few things:
- Doing cutting-edge research type programming and/or optimization (eg: DB design work, compiler design, optimizing embedded firmware, etc.)
- Doing necessarily complex functionality, and only if you _need_ it (eg: highly multi-threaded apps, lock-free programming, etc.)
- High-level design, organization, and/or refactoring for large/critical projects (eg: re-organizing the Windows/Linux kernels)
- Writing "optimal-to-maintain" code to do more with less people/time/resources (eg: having less than five people writing and supporting high value, expansive enterprise apps)

If you don't have one of those cases, "normal" developers will probably be fine (assuming reasonable management and organization structure). My 2c.

I am not a lawyer, but...

Based on (at least) the Barry Bonds prosecution by Congress, any potential witness should be able to assert their 5th Amendment right. Why? Because in that case, it was established that the government could prosecute you solely for your testimony, if they felt your testimony was not revealing enough, regardless of how accurate it was.

Under that precedent, it would be impossible to give any testimony without potentially incriminating yourself. Thus, you have a 5th Amendment right to refuse to offer testimony (unless the state offered you transactional immunity at all government levels for anything arising from your testimony, which would be highly unlikely). I'm somewhat surprised more people haven't realized the implications of that prosecution, but it seems pretty clear-cut to me.

Thoughts on a way to fix this sort of thing generally:

The government should define a minimum support window for software, say 5 years or so. From the point where you purchase a software product at retail (not resold), you are entitled to support for critical security flaws (ie: exploitable risks which you cannot mitigate with normal usage) during that period. At the vendor's option, that support can be either free software patches (with no degradation of functionality or additional licensing requirements/terms), full version upgrades (under the same conditions), or the release of the complete source for the product into the public domain (BSD-style). The last option would be the legally-mandated requirement if the vendor was unwilling or unable to supply one of the first alternatives. Companies could, of course, adjust pricing of their software as appropriate to comply with the mandate.

It's not a very clean solution, but it would do wonders to curtail the "forced paid upgrade" trend in software. Plus, companies with "good" support policies in place (both large and small) would benefit.

(Note: Developer, small dev shop, higher-priced software, same situation.)

If you distribute an "unlimited" version, this will be what is pirated; there's no value in having different versions. Also, if you have a key which allows "unlimited" access without secondary verification, this is what will be distributed on pirate sites.

In our experience, it took about a week from changing the key format to a new crack key being distributed. Obviously, this is for software which is "in-demand", but don't expect that implementing a new scheme with the same underlying characteristics will buy you much time.

For "good" protection, you basically need secondary verification which is "hard" to fake. Currently, that is hardware dongles or an online verification loop. Both of these can be pains for the users, costly for you, and/or prohibitive in some environments (online, in particular, doesn't play nice with classified government envs).

Keep in mind also: most people who pirate are not potential customers, at least at anything close to full price, but their experience using the tool may turn into a sale at a company later.

My suggestion: do what you can to track usage, but don't be overly obtrusive and/or try to prevent all piracy usage. Being able to watch and track, and act when appropriate, is much better than trying to prevent all piracy.

I'd upvote this more if I could. As someone who both codes for a living and hires engineers to do the same, what you are describing is exactly what I look for in an engineer. You can become familiar with more tools and methods, but at the end of the day, you [just] need to be able to solve problems well. The only additional challenge in the "real world" is breaking down larger problems, and solving them in "better" ways (ie: fits better with the rest of the system, is maintainable, is flexible, etc.).

Also, to add to this, the tools for creating eBooks (at least Kindle books) are pretty awful. For example, the "recommended" method uses a two-stage conversion, with a third-party app which isn't even supported any more. All the conversion paths mangle any custom formatting, in different (and seemingly unpredictable) ways, and generate "messy" HTML for everything. Alternatively, you can hand-edit HTML, and manually create any extra parts (eg: the TOC), because there are no automatic mechanisms to support features that office apps have had for literally decades.

As someone who has published an eBook on Kindle, I can tell you that it looks "bare bones". It looks better in google docs where I wrote it, but it was a PITA to just get it into Kindle format, and the tooling to "make it nice" without lots of additional effort was just not there. If Amazon et all could address that problem, it might go a long way toward getting nicer looking eBooks.

As someone who interviews and hires developers...

I think the brain teaser has a place, but mainly to gauge how someone approaches and thinks through a problem, not for any specific answer. I agree with the OP, though: real code and big picture thinking is the best indicator of longer-term success. On the other hand, you can be a good coder without big picture thinking too, especially in a larger organization with good engineering management.

Personally, I look for people who know how to code (ie: can answer intermediate questions), understand what the code is doing (eg: in C++, why you normally use virtual destructors, but in what conditions you may not want to), and can think through problems (ie: here's an arbitrary hypothetical problem, tell me how you solve it). If you can do those things, you can be a productive developer; the rest (eg: specific knowledge, familiarity with tools/paradigms, coding trivia, etc.) is gravy.

I do think this is valuable information, but it doesn't go far enough. You should be able to filter apps by permissions as well, on platforms which support per-operation permissions for applications.

You know what would be even better, though? If the per-operation permissions were settable on a per-application basis, and then spoofed/failed if the app can't work without it. There are plenty of apps that I want to use, but require extraneous permissions for things I don't care about, and/or don't want the app to access. If someone could build a platform which put the permission usage into the user's hands (even as an Android variant, for example), that would be awesome.

Not just local law enforcement. Any government entity, law enforcement or otherwise, without the bothersome inconvenience of probably cause, warrants, or any of that other pre-telematics nonsense. Hope you're not engaging in any activities which the government might think are supportive of terrorists (like, say, talking about seditious thoughts).

The fact that people buy cars equipped with OnStar is either a sign that we deserve our oppressive government, or is a testimony to the ignorance of the voting public...

I don't think the marketing is anything more than typical marketing optimism/BS, but to be fair...

If someone could make a smartphone that:
- Had a smooth ease-of-use of an iPhone
- Didn't require you to root it to fully customize it
- Didn't pack it with carrier bloatware
- Had good battery life and talk quality without building/flashing your own custom ROM
- Had lots of free and/or nearly free apps to cover common usage scenarios
- Guaranteed to respect your privacy (no CarrierIQ, tracking, logging, etc.) ... you could probably sell it pretty well. There's not a snowball's chance in hell that Microsoft/Nokia will produce such a phone, but it's true to say that there is a large-ish market which is being largely under-served by the current smart-phone offerings.

(Disclosure: I have a relationship with Lieberman Software, although I was not involved in this survey.)

Just because the company initiating the survey has a business interest related to the subject material doesn't mean the results are inherently BS. Sure, you should be skeptical, but to call BS purely due to bias seems... misguided.

For example, you readily state that you have access to shared passwords; thus, you would be included in the affirmative for the first question quoted. Presumably you wouldn't know if other co-workers thought you or other admins had misused access, but if so, then perhaps the second as well. You sound fairly security-conscious, so I'll assume your organization would not be included in the third... unless perhaps other admins are not as diligent as you (which, I realize, never happens in large organizations, but consider the hypothetical). Are the results of the survey really that hard to believe?

Sure, Lieberman Software is selling stuff, but it's not like they are trying to hide it, or hide behind proxy "unbiased" survey organizations. Read the info with a critical eye as appropriate, but calling BS due to non-obfuscated bias is as bad as believing the info on face value.