We have a pretty terrible level of unemployment and underemployment in this country and yet, many employers claim to have difficulty finding workers.

Why??? There's such a thing as supply and demand and at a high enough price, you can find someone. Employers may not agree, but that just means that they can't wrap their head around what they actually have to pay. And of course perish the thought of hiring someone who hasn't already done the job either. There's a shift of mindset that has to occur here about the pay those who can do deserve, and the opportunities those who might be able to should be afforded.

I have really mixed feelings here because I know a lot of good people here on H1-Bs. Here's the thing, in the short term people do compete for a fixed pie, and once you're out of this business for more than 9 months it's next to impossible to re-enter... I know a lot of people who found themselves in that situation, too. So, it's hard to make the argument that H1-Bs visas increase the demand in a way that's broadly helpful to the locally resident software grunts.

Of course, that's not the whole point... we are also, with competition trying to reduce costs and create positive ripple effects that increase competitiveness and aid hiring in other industries, too. And I do understand targeting... the "give me your poor" line on lady liberty is a beautiful sentiment but not sane U.S. domestic policy so you have to be a little choosy. So why not software?

If we are trying to do targeting based on a perceived shortage, let's go back to the laws of supply and demand and figure out what they're telling us. The most objective way to measure a shortage is not based on the amount of whining, but based on prices. Most of the highest paid professions in this country are in the medical field. I'm not saying that high pay isn't deserved, I'm just saying that the eye popping character of it all should command our attention and make us think about what it's doing to say, anyone who's sick without insurance and to our deficit. Rather unlike software, we have a compelling national interest in trying to supplement this labor market.

If you think IBM isn't getting paid a ton licensing its war chest of patents you're crazy. Estimates vary, but they are LARGE.

And that's not even the primary reason companies go for patents, especially the stupid ones.

The real reason to go for as many patents as possible is to have as many legal weapons as possible to bludgeon and gut any up and comers with a competing product. A protracted legal battle against a foe with those kinds of resources, even if won, will sink most companies.

In principle I agree and you should design and refactor as necessary to get your code as clear as possible. Some designs as you said, are so bad they're undocumentable anyway. (And actually, the relative ease of documenting code is the single best heuristic as to the maintainability of the design).

That said, even a nice design and code written "as clear as possible" is not good enough for the long haul.

This is irritating as hell because it seems so obvious right now... after all, you just wrote it and all the unspoken assumptions about what this is for, how it should or should not be used, and behavior in corner cases are known to you without a second thought.

Will they be when you or someone else has to come back to it months or years later? Of course not, that's what the comments are for.
There's a balance to be struck here, some comments are dumb... for instance, anything auto-generated or which just restates in imprecise language an adjacent conditional. That said, the amount of commentary your should write is always greater than your expectations.

If you haven't written comments along the way please, please get a code review now. Anything you've had to explain to your reviewer that's not already in a comment, put it in a comment. It's not perfect, but it's a start.

They won't and can't understand the value in improvements in test suite results or complexity measures.

Explain very simply.

Features are assets.
Lines of code are liabilities.

People confuse the two because you need some code to make a feature, but every line has a finite chance of creating a bug incurring a support cost, and whether it introduces a bug or not it makes for more code to sort through to find the bugs in other parts of the code.

The only real value of your application is in the features. If that's hard for them to quantify, that's understandable, but if that's hard for them to understand then that's insane. If you like, as a last ditch effort you might go back to the scenario oriented demonstrations that were convincing the first time but if that doesn't work, it's time to look for greener pastures.

Knuth lost his wager how many times?
Of course there should be reviews.

And yes, in the short term, it would benefit the reviewer more than the reviewed. Does that make it a bad thing?
Think about organizations with highly centralized expertise and trust vs. ones where it's more distributed.
Which are better places to work, keep better people and do better over time?
If Google doesn't they should start making him do code reviews.

Consumption taxes, when level and consistent are recognized as being really highly efficient and non-distorting in comparison to other schemes.

The thing that stinks is that those at the lower and lower middle parts economic scale generally consume just about 100% of their income.
As a result, this sort of tax hits them the hardest.

In European countries, this is offset by directed government largess. I propose that instead of directed government largess with all the complexity/inefficiency and corruption that invites let's have the government's largest expenditure be transparent, no strings attached supplementation of legally earned pay, per pay period.

That supplement could start at a fixed level and then match fractionally increases in pay with a lower fractional match as these numbers rise and eventually, past a certain good upper middle class income at which point the match should go away and it just becomes a fixed figure (if the desire strikes to have the this figure decline as income rises, you haven't set your consumption tax high enough). This paired structure would work like a progressive income tax in terms of who it draws revenues from and at what rate except that it automatically captures the black market, those who legally (but still annoyingly!) mooch off others, and those who inherited money from dead relatives and do nothing to produce on their own.

If the fixed initial supplement were generous enough to bring a household just past poverty level then you could make the statement that we have no working poor anymore... which would be a amazing. And if you'd take that level and add in current minimum wage, you could abolish the minimum wage, which would make more marginal people employable and provide a path for them back toward a law abiding existence. In fact I'd wager it would more or less solve the problem of unemployment except for those with pretty severe disabilities. If you have a good system for recognizing that and caring for those people then could solve the problem of poverty in this country entirely except for the very few who are capable of work, but unwilling to do so. I'm fine with letting them go.

Anyways, just a suggestion, and yes I know the consumption tax rate would have to to be very high to do something like this. I still think it's the right way to go.

This guy is a marketing/business guy.
The innovations he's going to care about in the game itself... there's nothing about angry birds as a game that would qualify.

It's the business model. So yeah, low priced cell phone games will be huge in terms of adoption, doubtless rivaling and probably eclipsing consoles and PC gaming because most everyone has a phone on them at all times.
Profitability, meh, who knows. But he's resting on a wild success story so he projects into the future based on that.

But anyways, hats off to him as a marketing guy, he got us talking about Angry Birds.

Right now gas stations have obvious peak times during rush hours. Obviously, nothing so ridiculous as everyone going at the exact same time, which is the best fit to your blurb, but still, high demand times nonetheless. And if we were talking about energy delivery comparable to how and when we gas our cars, I agree you'd have a problem. However, most people will get most of their juice at home overnight, which while increasing electricity draw, doesn't demand a bigger power station than we have now.

Charging stations will predominantly serve road trippers, and there's categorically less of that sort of traffic, and from my experience on the road, the "fill up" times are much more random and better distributed than on a day with a 9-5. These charging stations would need a lot of juice and possibly some special handling by the grid, but there wouldn't have to be such a huge number of these, so I think the challenge could be dealt with reasonably well.

My major concern isn't what the consequences would be if electric vehicles became ubiquitous, but whether this, like so many other stories promising great things for electric cars right down the road, will turn out to be mostly hype. The charging time statement is pretty incredible, and deserves scrutiny... how can you charge so fast without generating a ton of heat?

As are most managers.

haven't done this on a car, but I'll definitely recommend it for luggage.
Have nice cover since I'm always travelling with my wife.
Also got plaid luggage tags.
When luggage gets misrouted, all you have to say is pink with plaid tags and it gets back to you 10X faster than it would otherwise.

Implicit variables give some of the same convenience in programming as pronouns in natural language, except unlike pronouns, the implicit variables have the same meaning each time. I've never been a fan of Perl syntax, but if you spend any amount of time in Perl at all $_, and @_ should be old friends.

I think having form of implicit variables in the language is a great convenience feature and the only thing I'd say is that they should have names that let you know what you're dealing with without internalizing a table of (mostly) $<FOO>. But then again, we're talking about Perl here.

It's true that disks have been around longer and are cheaper to mirror, but proper wear leveling SSDs are the norm now, so reliability concerns are mainly FUD, and TRIM support is also the norm now, so performance degradation nearly as big a problem as it was. Importantly, there's nothing analogous to a head crash... if you loose data, it's at a much smaller granularity and more frequent than actual data loss is that blocks get marked as bad when the bits get stuck and you loose a little capacity over time.

Also, I'll say that in much much less than 30 years of experience, I've already seen RAID fail in a practical sense 2 times... that is two failures within the same drive array too close together to be replaced. One was related to ordering procedures and bureaucracy (2 weeks should be enough time to get a replacement drive), but another pairing of failures were only a day and a half apart... that's impossible unless you're getting your components from best buy. It makes sense... if you're using the same drives from the same manufacturing run in the same way, you're practically begging them to die at the same time.

Finally, I do support the notion of local nightly backups to disk for convenience sake, but the only truly safe backup is one that's distributed geographically as well as with repetition in media.

How valuable your computer's speed is to you depends on how valuable you consider your time to be. At home, maybe it doesn't matter to you, but from your employers perspective the value of your time is quantifiable... basically: salary+benefits / expected hours of work. Other people have already run their numbers and YMMV, but to me it's pretty convincing that the payback interval in terms of time saved is pretty short... not to mention the saved aggravation. CPU is the bottleneck a small and shrinking category of applications. OS bloat is inevitable, but you can pick a slim distro if you're feeling weighed down. In your list, that leaves fragmentation which is a problem tailor made for SSDs, because random access is orders of magnitude faster.

Man in Black: All right. Where is the poison? The battle of wits has begun. It ends when you decide and we both drink, and find out who is right... and who is dead.

Vizzini: But it's so simple. All I have to do is divine from what I know of you: are you the sort of man who would put the poison into his own goblet or his enemy's? Now, a clever man would put the poison into his own goblet, because he would know that only a great fool would reach for what he was given. I am not a great fool, so I can clearly not choose the wine in front of you. But you must have known I was not a great fool, you would have counted on it, so I can clearly not choose the wine in front of me.

Man in Black: You've made your decision then?

Vizzini: Not remotely. Because iocane comes from Australia, as everyone knows, and Australia is entirely peopled with criminals, and criminals are used to having people not trust them, as you are not trusted by me, so I can clearly not choose the wine in front of you.

Man in Black: Truly, you have a dizzying intellect.

Vizzini: Wait til I get going! Now, where was I?

Man in Black: Australia.

Being able to clearly make out the immediate section of road ahead (pothole vs. oil slick, to use your example) is much more important than long distance vision as long as illumination distance > braking distance(including reaction time). If you're driving faster than that, then you're an idiot.

Being blinded by oncoming cars with their high beams is a problem either way, but when I use my lights, I'm certainly not blinded for anywhere near 10s (maybe 2s) because my pupils are not nearly as dilated as yours. That, and other cars on the road can see me, so I'm less likely to be hit.

All around much, much safer to have the lights on.

Pull my finger indeed.

Add increased stupidity (poor public education combined with broader usage) to bloat in TGMLC to get a real sense for what will really be run on this fabulous new hardware.