I agree with you that this sort of publication of charges instead of convictions sucks.

However, your characterization of drunk drivers is just wrong. They ARE incredibly dangerous. They ARE reckless, and while they may not intentionally be seeking out people to mow down, they are showing a tremendous disregard for those same people.

Buying Chocolate when you wanted Strawberry is a bad decision. Getting behind the wheel while drunk shows a fundamental contempt for human life.

Attempting to trivialize it in the way you have is honestly quite disturbing.

Royalties for a text-book, yes. However writing a text book is not an expected part of a university professors job.

Creating lesson plans, however, is a very different animal. It's an expected and required part of your job. We (the taxpayers) pay teachers to create these plans. For a teacher to claim ownership of these plans doesn't make a lick of sense to me. Just because you 'do it at home' doesn't change it. If I write software for a company at home, I'm still being paid for that work and have no right to claim it as my own. There is no difference here.

I will absolutely not pay unless I can freely stream my Hulu content to my TV.

Denver is currently piloting a meter that is really nice. It looks like a traditional meter, but it accepts credit cards instead of just coins. Convenient, easy, and apparently not very difficult to retrofit.

How does this generate extra revenue for the city over the traditional system? The real problem these systems solve (and they are very widespread) is making it easier to support credit cards for payment. That's a huge convenience for most folks who don't generally carry change. I get that cynicism is ultra-cool these days, but it's hardly warranted in this case. This is an attempt to alleviate a real problem for folks (like me) who rarely have change. I've used the system in Portland, Denver, and several other cities both here and abroad and I see no issues with it.
 

That article had no statistics, just a guy who has had articles buried. It was all based on 'talking to his buddies' who have also had articles buried.

It may very well be happening, but that article/blog-entry thing provides no insight into what is going on at all.

Simply not true. Nokia S60 has a veritable ton of apps available. Palm has roughly a billion.

It's not quantity, it's quality of experience. Neither Nokia nor Palm have really made the process of locating and buying apps very easy. The iPhone has.

Google has built a promising system for Android, and as they get more phones to market you'll see more and more applications built for it. I think this battle is going to be fought on balancing 'open' versus 'reliable'. Is apple right? Can developers not be trusted to build high quality applications if the phone is largely open?

Time will tell.

The point is you don't have to do even that. The routine would look something like:

- User initiates action with the floppy drive
- Run the auto-detection routine to see what answer you get
- Spin up the drive and check to see if something is in the drive
- Compare that with the pre-spun result to see what answer you get.

Something along those lines. There are several variations on this that would work and never require you to interact with the user at all.

Taxes is EXTREMELY important here. Those shares are going to be taxed as income, even though they have no cash value (they will be taxed at the current valuation of the company at the time of the award). This can be a very significant amount of cash..

You should be looking for options, which allow you to defer much of that tax burden till at least they are liquid (but be careful how the contract is worded in terms of vesting and term of availability.

You sir have master (with incredible (and absolute)) skill the art of parenthetical (the use of parenthesis to denote (or markup (or provide additional detail))) writing.

My hat is off to you :)

It's always interesting when I consider the number of hard-core Republicans I know that happily take government welfare. Rural areas are FILLED with people who don't want to work (they're "contractors"), yet live on 5 acres and have 11 horses (real example). They need food stamps to get by. They depend on government medical coverage for their children.

Yet come election time they are red as red can be.

Just because sexuality has been overly criminalized by a prudish society is not the fault of those engaging in sexual acts.

Literally every single Windows user I know has been infected with this. I removed it several times over the holidays. My wife (and many of her coworkers) where infected...

I know it's not necessarily a representative sample, but I'd be shocked if it was only 400k machines in total.

How do you identify "good code"? That's one of the great problems we have as software developers. Quantifying 'good' code is extraordinarily difficult. Code reviews do an excellent job of identifying clever code, but rarely capture the full utility of what is being written. You may think you know good code when you see it, but over the course of my career I've become convinced that is not true at all.

Really the problem is that the only way to truly measure code quality is by seeing how it runs in a production environment. Even then I can easily quantify the quality of the teams overall output (does it work? does it work consistently?), but tracing that back to an individual programmer is often nearly impossible. Systems tend to interact with each other, and placing blame is not an exact science. The gulf between 'good' and 'good enough' is not nearly as wide as it seemed when I was a novice programmer.

Great code almost never breaks. Good code works most of the time. Poor code is another matter.

Poor code is easy to spot. Poor code never works. It's ugly. It's complex. It's stateful. It's jump off of the screen and practically begs to be put out of its misery.

That's precisely why companies have processes and checks. They are an attempt to catch marginal code and make it 'good enough'. The problem, as the article points out, is that in the process they often inspire great coders to deliver marginal code themselves.

The secret is to spot (through some mixture of science and art) great programmers and provide them with the freedom to write great code. If circumstance requires you to hire marginal programmers, then by all means put the process in place to make sure that what they do doesn't detract from the work your best and brightest are doing. Separate them as best you can. Limit how their systems interact.

But whatever you do... don't limit your best programmers, as they are far more valuable than hundreds of poor ones.