As people above have pointed out there should be a minimum salary for H1-Bs. This salary should be borderline absurd. Then on top of that there should be a special H1-B tax on that salary bringing it down to below what is typically earned in that field. Then 100% of the tax should fund education or training in that exact field. So if H1-B programmers are hired it goes to programming education. If H1-B snake charmers are being hired then it goes to a snake charming school. This way the government doesn't pick winners for educational grants, they pick themselves.

At no point should it be more attractive to hire a H1-B than it is to hire a local of the same qualification. If the system was properly tuned it would always be a last resort to hire a H1-B not the preferred case as with many exploitative companies. Then in theory there wouldn't need to be a cap.

Personally I have always thought that any work you hire in cheap countries should have their labors taxed until the domestic company had paid the same as if the work were done locally. So if you have a company in country X that is getting the work done for $0.50(shipping included) per unit because they pay their people pennies and pollute the crap out of some river and the domestic rate is $1.00 per unit then there should be a $0.50 per unit tax. So if you think the offshore company does it better then you get them to do it. This prevents the economic concept of us not only importing their products but prevents the import of their crappy standard of living.

Oddly enough the above idea encourages simply paying higher wages when you do find yourself having to hire outside help. Thus raising the standard of living in other places.

There are so many exceptions to this "rule" that it is at best an interesting pattern. There are big turtles that live great long lives and big turtles that don't with little turtles being all over the place as well. There are birds of all kinds of sizes with small birds that live 80 years and big birds that live under 20. Some bacteria seem to be nearly immortal and others live days. Within dogs the big ones hardly outlast green bananas while the little ratty ones go on for decades. Poplar trees grow huge and die fast, oaks go on and on but some smaller trees are thousands of years old.

Even humming birds live a few years at crazy heartbeats as high as 1200 bpm (look it up if you don't buy that mind blowing number) yet other bigger birds with much slower heart beats live for the same length of time. So it isn't size or heartbeats.

If I had to suspect anything lifespan will be an evolutionary advantage like anything else. If you are surrounded by ever changing dangers a short fast life-cycle is probably best. But if you are fairly safe in steady environment a long life is probably safer. Turtles have slow metabolisms which allow them to survive long periods without food and are fairly safe from predictors so they don't have to worry about adapting too much. Rabbits are basically the forest's McNuggets so they need to continuously adapt in numbers and probably other things such as coloring; hence a fast short life cycle. We have created civilization where we are nearly 100% safe from predators and with things like food storage are not so buffeted by a changing nature; so we are getting longer an longer lived.

With out a doubt you need to be able to measure what works and what doesn't but the moment some first turns to any kind of standard or the nightmare word "metrics" you have already failed. Too many companies go through all the fads and all the silver bullets. They have scrum masters, and black belts in Six Sigma (I am not making up the black belt part) but the fundamental problems are not fixed. Often the first place to start is with communications. Who does communicate and who is supposed to communicate. It is great if the sales people can bounce stuff off the programmers in the lunch room and even better if the programmers meet the clients but once the sales people are able to direct a project the project will instantly start chasing rainbows.

The second place to look is the why? Software is made for two reasons, to make money or to avoid losing money. This allows you to boil down any "solution" to the money. So if the argument gets into religious territory such as language choice, OS choice, documentation, or even commenting style you can then ask, how does this either make us money or prevent us from losing money? So someone might say, such and such a documentation system is better when you can then ask, lets look at the cost or value of us having no documentation at all vs perfect documentation. After breaking it down you might find it is a huge cost one way or another and your decision is made for you. This prevents programmers from continuing to try and impress their long past CS professor and his insatiable demands for Hungarian notation. But as a pro-documentation example if you are routinely cycling in new programmers into a project great documentation can pay for itself in spades; but first you must calculate the cost of bringing a programmer into a project sans documentation and bathed in documentation. Did that documentation save more than it cost to produce; you might argue that a good documentation is low cost but again compare that low cost to the cost of not having it at all or having less.

So better engineered high quality code feels like a great idea but make sure that the value of increasing quality does not have a disastrous business result. A simple example would be if your company's business is famous for being first to market with each new feature. People might grumble about how it crashes quite a bit but that since they make $500,000 a day using each feature having it a week earlier than the rock solid competition is very valuable. So if you slow the process of delivery down by 8 days and make the software perfect you will be out of business in no time. This is all a bit extreme but I suspect your core business is not making software but doing something else that the software supports. So it is quite possible that your company is mildly irritated by the bugs but that they exploit the features quickly.

Personally I have found that unit testing on larger projects ends up speeding up deliveries but on smaller projects definitely delays delivery.

One bit of horrible experience that I have picked up over the years is that some great systems were built on truly terrible code and truly terrible architectures. The disasters were also legendary but more often than not the cost of the disasters still justified the speed to market of the terrible system. Some systems were then recoded after disasters and made great but often at the cost of many release cycles resulting in a business disaster far greater than the disasters prompting the recode. Often the best solution was to make the code base slightly less terrible and press on at full speed. I have seen this terrible code and it is just solid WTF but when you look at the piles of money generated you just get angry that your own "perfect" code didn't make you rich. But as a counter point I have seen systems so terrible that the disaster took out the company; but even there just a slightly less terrible system would have saved the company. (The example I am thinking of had no backups so they lost everything, POS, inventory, customer lists, and codebase leading to bankruptcy. So with only the addtion of backups a terrible system would have continued to fuel an otherwise solid company.)

To give a more physical example in WWII the Russians made terrible tanks; the welds were crude, the whole thing a bucket of bolts run by a badly trained crew. The German tanks were marvels of Teutonic precision; well trained crews in great works of engineering. But the Russians churned out their tanks with great thick armor and ever bigger guns. The factories were famous in that they were within earshot of some battles and the virgin crews would climb into their unpainted brand new tank and their training was largely gained as they drove to the nearby battle. The Russians ended up kicking the German asses. If you were unaware of the historical outcome and you looked at the numbers, the actual tanks, and the comparative experience and training of the crews most people would agree that the German superiority was beyond consideration. But again a counterpoint can be found in American tanks in the Iraq war. The Russian tanks were crude and again had the advantage in numbers but the American technical superiority so overwhelmed them that I felt a tiny bit bad for the Iraqis. My conclusion is that engineering superiority is sometimes good but sometimes bad. You have to figure out the cost to each option and you have to look at the benefit to each option. These costs can be very hard to pin down (such as the cost of it being hard to find good programmers to work on a bad project) or easy (the cost of a great programmer). Then you look at these money based numbers and the decision should then be as easy as greater than or less than.

I commissioned a study "for internal purposes only" that proves that day is night and that night is day and that all astronomers have been totally wrong to this point. But after spending millions making sure that the press prints summaries of my study I will not be releasing the study to analysis (and ridicule).

Microsoft full well knows that at this point the whole Microsoft vs Linux you must appeal to the faithful of their religion who will studiously ignore the ravings of the pagans and will hang on to every word coming from Mt. Olympus in Seattle. So microsoft doesn't need to publish this study. Its mere existence is enough for the embedded (and often well microsoft certified) IT staff in any organization to counter the 10 Million dollar savings. This 43 million savings not only is much better but will work well when a meta study is done and totals up the averages. So even if 3 other studies confirm the 10 million in Linux savings the average will still accrue to Microsoft.

Personally my experience is that Linux can be a great replacement for most but not all day to day systems. With most corporate software solutions going web it really doesn't matter which platform you are browsing from. Most employees of large organizations are shockingly unsophisticated users of the software so will rarely even notice the difference. Where you often run into problems are when legacy windows based software must be installed on many systems such as some kind of timesheet software. But a linux switch often works well as long as you let those who need Windows continue to use windows (say the accountants because they are extreme power users of Excel.) But there are other huge savings to be had by tossing Microsoft. In an all open source system licensing is really really easy. Then there is the fact that Linux can be so undemanding on the desktops that you can cut way back on system upgrades.

But there can be weird costs such as printer X that might not play well with Linux. That can offset some of the lesser hardware savings. You can be suddenly restricted to not being able to deploy certain windows only solutions.

The key to succeeding that I have seen is to start small. You take a small typical department and start switching the machines over to Linux and see what happens.

The key to failure is to let a small group of senior IT people with Microsoft certifications up the wazoo bring in MS sales people to help them thwart the effort. You can tell when this is happening when suddenly random senior management start protesting the potential switch to Linux armed with bundles of studies proving that the organization will be cursed with locusts if so much as one machine is converted to Linux. These will be people who were asking for an Apple laptop the week before.

I used to see a fair number of errors(crashes) that were both java and .net on many huge sites. But now I primarily see errors from crashing java sites. That could be due to people dumping .net, .net cleaning itself up, or .net programmers getting better. Personally I don't use either (did years ago) but the huge number of errors that I would see on what should have been well developed sites is what kept me away going back to either.

Now on smaller sites I see PHP crashes but I would expect to see more people using PHP on smaller sites and more people using it badly.

What I would love is a survey from say google showing what technologies are used on sites getting 1,000,000+ hits per day and what their error rate is?

There need to be consequences for prosecutors who abuse their positions.This could be done mathematically. One abuse is when prosecutors level massive charges with the goal of pleading them down. Thus there could be a maximum ratio of charges laid vs convictions/pleas on those exact charges. Another abuse is the investigation itself. So there could be a maximum investigation to conviction ratio. Also there could be a maximum time for an investigation. If someone is investigated for years and years the drain on them is nasty. So it should require a judge's approval to continue an investigation past a certain amount of time. For a crime boss this could be a great long time but for some dumb computer case it should be 30 days or less.

When consequences kick in there should be both penalties to the prosecutor and benefits to the investigated. Much like the double jeopardy if you charge someone with something serious that you can't make stick it should then be impossible to convict them in revenge on a minor related crime. So if you charge some hacker with RICO and massive fraud but can't make it stick you can't then convict him in revenge for mail fraud because he filled out some form wrong.

Then there is the prosecutor. If these ratios are passed by a certain amount the prosecutor should immediately be suspended and their continued employment up for review. Pass the ratios again and game over they lose their job.

The last option should also be that the defense can have a single prosecutor removed and assigned to a random other prosecutor. This way the "career making" cases are then less about politics and more about justice.

Much of code is a matter of taste:
if(x==1){bla();}

if(x==1){
bla();
}

if ( x==1 ){
bla();
}

if(x==1)
{
bla();
}

Are taste. Comments and variable/function names are functional and thus more arguable (but still generally religious). Any review of this sort that talks about code formatting is wasting our time(unless they went way overboard with something stupid) with religious nonsense so I wish he would stick to the benefits of how they pass parameters etc.

The only time anyone ever "Wins" the code formatting argument is when something else is brought into the argument such as "Format it my way or get fired." or "Format it my way or I quit"

Nearly every place I worked had someone who always began the argument about coding standards with "I don't care which standard we use as long as we all stick to it." But then they relentlessly argued for their standards and wouldn't give an inch with well structured arguments for every space, comma, and return. Often these standards had all kinds of specific metrics like a certain ratio of comments to lines of code. This way they could point to other people's code and mathematically prove that they sucked. Although the worst were the passive aggressive sorts who would reformat any block of code they touched on to "their" standard which was wildly different from the entire rest of the programming team.

I hate any company that is driven through spreadsheet thinking but I think this story only really applies to the Zyngas of the world. My beef is a little bit different. It is where multiplayer games slowly cut off all the interesting discoveries. Too perfect a sniping spot; modify it to make it vulnerable. Room too perfect for a grenade tossed by a defender; change it. Gun a little too powerful; tone it down. All these fixes make eventual sense in that once enough people make one of these discoveries then they exploit the crap out of it and it really ticks the other players off. But at the same time these discoveries are cool. When I find that perfect ambush site I will annoy a bunch of players until they just start tossing a grenade into that spot every time they walk by. So if the spot is too perfect by all means fix it but then create another "too perfect" problem. Let people find it and then fix it. Too many multiplayer games get fixed until it is just a boring stalemate while other games never get fixed and that perfect sniping spot just runs all the other players out of town. In real war you often have move/counter moves the whole war along which is the thinking that drives the whole "Fighting the last war" syndrome where after the war the winning side keeps countering the enemy's last move better and better. But in many games all the counter moves just fix existing problems while not actively seeking to create new ones.

Very dangerous as we don't always need awesome programmers. Often the high-school student programming up a school website is just right. Once you have a PE you will then get "Professional" bodies that will then prevent the high-school student from programming and then poof prices go through the roof. But while that might look good I can give a great example of that blowing up the second the Professional society gets greedy.

In Nova Scotia years ago if you bought a house you would pay a surveyor around $100 to walk around a property to make sure that the house was thoroughly on the property. With few exceptions the surveyor could eyeball this so it was an easy $100 for every house sold. Then the NS Surveyor's "Professional" organization insisted on a full survey for every sale which would cost around $1,000 (at the time) but some smart insurance person said, "Wait a second how often does it turn out the house isn't on the property?" So he started selling insurance, for $100, to the buyers that he would cover all the liabilities if it turned out that the house wasn't on the property. This satisfied the banks and was easier than getting a surveyor to eyeball it. So now all the surveyors lost that nice little side business of $100 for every sale and certainly never gained the $1,000 business. If you do the math it is $100 time the number of buildings sold in the province. That is a huge massive loss for the small number of surveyors that existed at the time.

So if any state or province were to try to create a PE designation that had the slightest backing in law all that would happen is that on paper it would look good but everyone would figure out ways to end run the system. Instead of hiring a local developer you would outsource(out of your jurisdiction) to someone who might make you a "Shrinkwrap" solution that you are the only person to ever buy. Or even worse the law would be written that you can't use software not certified by a local PE resulting in that government losing the next election.

The PE designation and the laws backing it only make sense when you are talking bridges or other engineering where lives are at stake. PE laws don't exist to protect the top people in the profession from being embarrassed by those at the other end.

I wish that they would do this sort of thing here but I just know that what would happen is that the government would cave into lobbyists that would then set up the regulations that didn't boil down to houses needing to have a fiber hook up but to pay the telcos to have fiber. Then the telcos could call it "building infrastructure" instead of "lining pockets".

But instead of creating the conditions for all people/companies to thrive the government they will keep trying to pick winners. In my area the government recently gave hundreds of millions to two failing pulp mills. The very word mill evokes images of 1920. "I goin' to quit school and work at da mill like me grandpappy."

Insulting but necessary; recently I a friend who is an awesome coder walked out of an interview when they handed him an final exam like coding quiz. He felt that it was too impersonal a way to assess for a position as the lead senior developer for a company. But at the same time I would say that the vast bulk of people I have encountered in the programming world were shockingly short of programming skills. A few years ago I developed a system for a company that then was handing it over to a company with whom they had a maintenance contract. So the two top programmers for the company with many years of programming experience and one of whom had graduated from one of Canada's "Top" CS programs began asking me interesting questions about my code; the most critical question was "What are those odd arrays that you are using?" The odd arrays were associative arrays. So I just thought they used a different word so I began thinking of anything even slightly synonymous, hashtable? Lookup table, map, key/value pair? In the end I gave a more than one hour tutorial on the value of a using keys to find values and how the hashing and use of trees could make the underlying algorithm wicked fast even on massive data sets.

The questions went on and on. Won't that waste too much memory (it was a single purpose server with 8G and a data set well under 500M)? Won't scanning through that huge array take forever(I had explained the whole look up tree and showed that a typical lookup only took a tiny handful of steps and that it didn't matter as the system was wicked fast even with a test load many times the system growing far beyond the company's wildest dreams.)

But these two who I now refer to as the Hash Twins could talk the talk. They would blah blah about log files and in-line assembly and wanted to argue about commenting style but had massive gaps in fairly basic bits of programming. So these two would have interviewed quite well unless your interview was basically a coding test. A timed coding test also makes sense in that if you gave me the weekend to pass a basic test in a language that I am very unfamiliar with like Haskell I could probably pass but I would have to look up nearly every bit as I not only don't use Haskell and am unfamiliar with functional programming so I would not be able to step into a complicated Haskell project as the technical lead. I shouldn't pass.

But even after years of C++ I would fail if you gave me a test full of pedantic questions such as "List all the different basic ways you can use the keywords static and const, define the following keywords: explicit, compl, noexcept, and decltype." (I had to look those up)

So I would think that a basic filter test should be quite understandable where you give a person a machine and say, "In the language of your choice code me a function that takes an integer and returns and integer of that Fibonacci number." or for a database person say "Given this trio of tables(users, products, and product sales) cough up an SQL statement that pulls up a list of all the Canadian users and a count of product X that they bought and include those Canadian users who bought nothing." If you couldn't do something that simple in less than 20 minutes (assuming job relevant questions) then an interview would be a waste of everyone's time. I am also willing to bet that the two above questions would kill more than 80% of applicants around these parts. Also questions like the above allow the user to show their thinking; do they put in error conditions? Do they use stupid variables? Do they do it in 10 seconds really well or do they sweat out the whole 20 minutes and produce marginal crap? Do they show a lack of Mathematical ability by asking what the Fibonacci is (Not a deadly strike but a test to see how broad their knowledge is as great CS does use math. Plus if they don't know Fibonacci it only takes a few seconds to explain)

There needs to be a new law that makes it clearly illegal for the police to interfere with someone recording them in a public place. Given the fact that police can be menacing it should be illegal for them to even ask you to stop or actively try to block you. In the same way they can't continue to ask you questions once you invoke your right to have an attorney present and have invoked your right to silence. The penalty for the law should be multi fold. Potential felony for the cop but also a minimum fine partially payable to the victim. This would serve to get more people videoing the police and the insult of the police having to write out checks to people they tried to intimidate would be golden.

The next tier of offense would be if the police then erase the video. With that there should be a minimum mandatory sentence along with a huge fine, again with much going to the victim.

Lastly there should be no exceptions tossed in as the slightest wedge given to the police would be abused to hell; So no being able to say it is evidence. If someone videos the police then the video should be as sacrosanct as client attorney privilege; if they want to youtube it then fine if they want to keep it safe then their choice.

It all boils down to information is power. Previously it was the whole your word against a policeman's which basically made their side of a story the only side of a story. But now the public has massive power not only through the video but through the near frictionless ability to distribute that video. 20 years ago if you were to say video the police pulling over a clearly drunk powerful politician even the local media might not touch that video assuming the police let you walk 5 feet away with it. Now you put it on youtube and the police suddenly do their job and charge the politician and while the prosecutor might not go for the throat will at least go through the minimum motions.

But all arguments that this somehow interferes with the police being able to do their jobs is false. The police have the clear ability to abuse or not abuse their power. But someone videoing the police does not change what happens they are not able to create abuse they can potentially try to show something out of context or add a colourful commentary but most people aren't stupid and will see through that in a flash. My guess is that any policeman that gets frustrated with being recorded is a policeman who doesn't want to be forced to obey the rules or knows they just broke the rules. They are lashing out because of frustration not because they think they are in the right.

This all reminds me of a local Indian restaurant lashing out after being closed for a zillion health violations; they argued that the health inspectors didn't understand Indian cooking nor did they think the health inspectors had any right to be in their kitchens. They argued that their insurance didn't cover health inspectors only employees, that the health inspectors were exaggerating, and that the inspection reports should not be public as the public wouldn't understand them. These all sound like the arguments that police make against recording them.

I don't want a Shuttleworth phone, I want a linux capable phone. I want a phone so controllable that if the phone is capable of doing it then I or someone else is doing it. The ideal phone would be one so controllable that some hardcore dude would instantly cobble together a complete command line interface to the phone:

phone-dial 5551234
sms-message -u5551234 'I will be 5 minutes late'
list-recent-calls
I am sick of phones that are missing features that would tick off the telcos. I want to block text messages from certain users (I'm looking at you Telus) I want to have a list of people who can and can't call me at certain times of the day. I want to block calls from certain callers. I want an easy button to turn my cell data on and off. I want to delete any app that I don't want. When (not if) I reinstall the OS I want to strip out everything and then put back only that I want (I'm looking at you NewsStand). Whereas I see an Ubuntu phone as being Shuttleworth trying to get his piece of the appstore pie. I want a phone that cannot be locked to a carrier.

Your operating system, almost all shrink wrap applications such as MS Office or Photoshop, Your console's operating system, Your games, Your microwave's OS, Your car. C or C++ but even the C++ in most of the above systems is more C like than C++. Where people mistake the popularity of Java is that many of the jobs at hand such as the local phone company's new billing system will be in Java. But the code that makes the phones actually ring will be something more hardcore such as C or even erlang.

So most of the public will go through their day probably using C or C++ based code 99% of the time and a bit will be say the timesheet software running Java that they access through their C based browser using C based network drivers on viewed through a video card with C based drivers on a C based OS with their packets going through C based routers and switches after using a C based security system to get into the building where they used a C based elevator system to get up to work. Of course many of the above systems use a smattering of other bits such as scripting libraries but those are being run by a C library. The only other language that the average person might encounter would be some Objective-C on their iPhone or some Java on their Android; but again those OS's are basically C.

When they get home and browse the web they then get the full onslaught of servers running a dog's breakfast of PHP, Java, RoR, etc. But those servers are all programmed in.... you guessed it C.

Quite a few people are using the NDK and programming in C++ much to the chagrin of Google. So technically there might be 10-100 lines of Java loading 20,000 lines of C or C++. A great place to get started is: http://www.raywenderlich.com/11283/cocos2d-x-for-ios-and-android-getting-started

Here they have the most popular iOS game development library ported for programming on android in C++.