Stallman has nailed this one big time. I see no reason why the 60 Walmart family members should earn what tens of millions of the bottom Americans earn. I would even go local with this one. That if in your region there is only one grocery store chain then it should pay much higher taxes than a new smaller chain looking to offer competition. The same with telcos. The big ones would be nailed and the new smaller hungry ones would have some breathing room.

This is not just about some commie redistribution of wealth but often smaller businesses are able to provide a more human type of business but if they are pressured into economies of scale then they are encouraged to not grow for growth's sake.

But I have a second suggestion. Salary / corporate income taxes should also be proportionate to how the employees are all paid. Pay low wages and the company along with the top executives pay a much higher tax rate. This even nails the small businessman driving around in a $100,000 car while his employees might have trouble feeding their kids properly. So the executive acting out of pure greed pays the employees more.

Some caffeine from Green Tea keeps me programming, driving, studying, etc. Red Bull makes me wound up and literally makes my heart skip a beat every now and then. Straight caffeine pills just knock me out and a few hours later make me angry. So needless to say I limit myself to occasional green teas. (Matcha!)

If my wife has a coffee after 6pm she will have trouble sleeping that night.

My brothers can't operate with much less than 5+ cups of strong coffee per day.

So needless to say within my reach are a pretty wide set of reactions to caffeine. The drug I would love to see studied even more is Chocolate.

I would up-mod this had I the points. I can just see the whole appendix thing; awesome visualization. My guess is that some prude downmodded you. Or some PR flunkies. Too bad you went with the Anonymous thing.

Steve Jobs took flash out behind the woodshed and flash didn't come back for dinner. I can say without a doubt that flash is dead, yet if I wanted to counter my own statement I could easily pullup a massive pile of stats that would show Flash on a huge percentage of machines and websites but I can see clearly that no even vaguely bleeding edge websites use it. Flash is just not where the cool kids are. HTML5 has almost entirely taken over all the basic requirements of making a dazzling website that dances about on your screen. I also won't argue that feature for feature HTML+Javascript is better. I know my HTML5 will work on the tidalwave of mobile devices and that is enough for most people.

That all said Jobs killed it because Flash bugs were making him look bad. So now we have round 2 and Java is the one on the Apple chopping block. I think we can all agree that Java in the browser is dead and killing Java on Apple machines might not seem like it is going to ruin things marketshare-wise but keep in mind that many top top top executives are running Apple machines (often to the chagrin of their IT people) these same executives will now resent Java at tiny more than they did before (which might have been zero).

But all that said, I am pretty sure that 90% of the Java being written these days is for the server side of things in large organizations and thus is completely unaffected in theory.

A simple example of how irrelevant such an Apple technology choice can be would be the penetration of Objective-C outside of the Apple ecosystem. I code Objective-C every day and would never consider using it one inch outside of the apple ecosystem. But Apple's move underlines my experience that Java is just not the "Hot" language it was; not dead just not "hot". The mathematical problem with not being the "Hot" language is that it is starting to be nibbled away at the edges without any growth to replace this nibbling. I am seeing Python replacing it as the defacto learning language much as I watched Java replace Pascal as one of the defacto learning languages of the pre 2000's. In science Python is taking over, in finance I am seeing the academic world switching over but not the business world; the business world has a full on love of all things Java.

But before you cast any stones these are all trends; you can yell Hey Mindcraft is Java and it is cool. But what I am saying is that the surface area of Java is retreating toward a core of the business world and it is severely losing its grip on the "programming 101" world; which is where hearts and minds are won. Also keep in mind that many of the kids who may have been learning Java in their programming 101 classes just had all their code die seeing that university students so love their Apple laptops. Hearts and minds baby.

Some MBA heard that x% of employees are earning a few dollars on the side and they realized that this could plug some budget holes (holes created by administration taking trips to Hawaii to learn the latest in ed-tech).

But in classic MBA style they forget about incentive where if they take that money then the work won't be done. I suspect that again in classic MBA style that they need to "centralize" and "quality control" information leaving the system.

This probably all stems from a requirement from some way overpriced anti-plagiarism software; even worse the pitch from said salesman might have documented (with great pie charts) that by doing this money grab the anti-plagiarism software would effectively be free.

Lastly by claiming copyright they get better control over information that makes them look bad. So if some student makes a video of a drunk teacher and puts it on youtube then the school system will demand that youtube take it down on the grounds that they have copyright. I would love to see them trying to apply this to teachers with blogs, twitter accounts, and writing op-ed pieces for the local newspaper. These fools forget that there are a zillion places to put a drunk teacher video that will oddly enough defend the students' first amendment rights.

To me this is just another great lesson for the kids that they learn that the educational system exists not one spec for them but entirely for the administration. In Ontario, Canada the school board got completely screwed by the government (before they screwed the government) so now like petulant children they are trying to keep the teachers from extra-curricular activities. They are now arguing that holding back these services won't harm the children. Whoa, wait a sec. Losers.

I really want a ban on places like Malls being able to install stuff that watches for my phone's unique identifiers to watch me move through the mall and returning to the mall. And I want a total ban on my phone company sharing anything about my movements or calls with anyone including police without a warrant and "trusted third parties" I don't trust any third parties so their aren't any "trusted third parties"

Taking chances, dancing near the fire, I love them. This is science done right. I am glad they didn't listen to some risk adverse nitwit who would rather have a useless "successful" mission than a risky useful mission. This why we have curiosity tramping around on mars with a computer with 2G of storage on it. It probably was the only computer to be able to pass all the bureaucratic tests as opposed to some simple physics tests. But if it fails not a single stone could be cast at the guy who picked it.

"Brogramming" (horrible term) and highly engineered programming are both great solutions to different sorts of problems. The key in choosing which is how well mapped out is your destination. If you are building a banking system where customers will engage in known transactions resulting in a known data stored in the database then the backend of this system obviously demands a very carefully engineered solution. But for that same solution the front end should be pretty damn freeform. People should try a bit of this and a bit of that feeling their way to an awesome UI. The back end engineering will dictate what data needs to come in from the UI and what data needs to go out but a great UI comes from a combination of requirements, gut feelings, fiddling, artistic balance, etc.

Then after the UI is ready for polishing you might go back to a more engineering approach and try AB testing where you watch the speed at which a user uses the system along with other measures such as number of mistakes.

Personally I find that people who hate the free form programing tend to be those managers who just don't trust their employees. They want to lay everything out in a design document that then locks everyone into a my-way-or-the-highway approach. This is a great way to get your best programmers to find another company to work for. Also my best programming has come from those times that I went down 5 dead ends and the 6th was really cool. But the 6th naturally evolved from what I learned in the first 5. There is no way that it would have ever have been conceived in a design phase.

There are many things that can cause inertia that are not directly related to the code. A simple example would be unit testing. (I love unit testing) but if you are going to completely redo your system then much of your unit testing goes out the door. Your carefully written documentation is garbage. Your design documents are all garbage, and any work you have done in planning version 2 or more is trashed. This makes drastic alterations much more costly than just the programming. But the reality is that you should never produce a bad product because the paperwork got in the way of switching it to a good or great product. This is sad because often if all that needs alteration is the UI where a well engineered code base should have fairly good UI abstraction and thus a new UI should involve little fundamental/programming work.

Really which is used and when it is used comes down to great managers. They will focus the freeform programming on organically finding cool ideas while not chasing rainbows and at the same time making sure that the fundamentals are well engineered. Within any team of programmers there are usually those who prefer one or the other anyway.

Obviously a large project has to have an overarching design and direction but a great example of a failed top down aviation design would be the Space Shuttle. They designed many of the larger systems in oddly specific waves of a wand and then left it to engineers to actually invent them. A really great example of this failure were the cryopumps for the liquid hydrogen and oxygen. This things had to pump a swimming pool of fuel every few seconds and were beyond anything anyone had done before. Yet they had to fit into a specific space and last 25 flights or more. But what happened was that they pumps could not be built to last more than a flight or two and thus became part of the servicing between every flight. The problem was that they were buried deep inside the engines and were a royal pain to replace. This plus a zillion other similar high level decisions resulted in each shuttle flight turnaround taking forever an costing way too much.

So if you look at the Space X people they are doing the opposite and seeing how good an engine they can build and then plopping a spaceship on top of that. This is how functional companies that don't have too much MBA management bloat engineer things. But my guess is that instead of Boeing just designing a better airplane with composites and seeing what interesting things could be done they made a long series of "executive" decisions and then told outsourced engineering teams to make square pegs fit into round holes. This would be as opposed to a healthy back and fourth where a high level goal is set, the rubber meets the road engineers give their feed back that changes the high level design which results in more feedback until you have a solid high level design that the engineers are fairly certain they can design.

I suspect nearly every programmer here has had a taste of this when some MBA type demands a costly feature that when all is said and done will be used by one person to very little benefit; all because there was no real feedback mechanism to say "whoa there dumb feature."

I have had a long standing bet as to how long it would take for someone to really nail most of the routers out there. It has always puzzled me how something like Linux or Windows can have a vulnerability of the week which is (usually) patched by most users in a flash. Yet there are many very old d-link, linksys, etc routers out there doing their thing without being massively attacked.

The closest that I have seen to a good widespread attack was when a certain DSL modem would crash when script-kiddies were attacking NT machines and the same attack jammed up that model DSL modem. That wasn't really an attack and it didn't amount to much.

So my bet still stands with modification: there will be an attack, it will be soon, it will be a worm, and people will (mostly) be blissfully unaware of (why is my internet so slow) it and certainly be incapable of dealing with it. Thus it will come down to the ISPs to deal with it which should be interesting to watch.

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?