It's really simple:
If you have a job, you can get a job.
If you don't have a job, getting a job is harder.

"Promised" is an elusive word, but assuming that the $70K offer comes thru, why not take it unless he has a gaming company offer in hand? which I assume he doesn't. It's always a good thing to be able to afford housing and food while looking for the job of one's choice.

Besides, he might be surprised, and like the promised job. (Or, it might be a small step above a Siberian work camp. One never really knows about these things until one tries it; but of course the same goes for the "dream" job at a gaming company!)

Whether coding standards really matter for maintainability generally depends on how much information you expect to be carried by the formatting.

We generally assume that indentation follows block structure, so indentation standards tend to be very important. I've wasted hours over bugs that were hidden by incorrect indentation.

Naming conventions may matter if the coding standard dictates a different styles for different scopes (e.g. LeadingCapital for global names, etc), or if type info is embedded in the name (pszFoo, lBar, etc).

Beyond that, coding standards help readability but that's about it. That may or may not be an issue depending on the team involved; one benefit of a uniform look is that you get less of "You're stuck fixing that code forever because I can't read it".

Whitespace standards (outside of indentation) are generally of marginal to no use IMHO. I'd follow reasonable whitespace standards, just for that uniform look, but nobody should be spending hours on it. The fancier the coding standard, particularly as it applies to variable naming, the less useful it is in general.

You shouldn't be losing "hundreds of hours" in code reviews, though. Either you're deliberately being obtuse about things or your coding standards are insanely complex, or uselessly ambiguous. There are a number of things I don't like about the coding standard I work in now, but I stick to it anyway because it makes the code more uniform and easier to read. Have you tried doing the same?

The latter.

AOA indicators aren't perfect either. What do you do when the AOA vane ices up and sends an incorrect position? It's easy to say "add sensor X" but then you have to deal with the implications of sensor X failing or sending bad data.

The biggest issue, quite frankly, is that the pilots didn't do anything they were supposed to do. They didn't perform the lost airspeed procedure. They used low altitude stall procedures when confronted with a high altitude stall onset (the two are very different). It was a thorough screw-up from beginning to end, unfortunately. The contributions of the airframe design to the accident were minor at most, and it's difficult to see how presenting different information would have helped a couple of pilots who had already ignored everything else the airplane had told them.

and airliners.net also. The ones who know what they are talking about are unanimous in that it had little to do with the non-backdriven controls; the pilots flying were so disoriented that it probably would have taken a giant flashing sign saying "you're falling out of the air, dummies!" to get them to nose down.

And anyway, FBW != back-driven controls. The thread title is wrong and misleading. Boeing uses FBW too, but they back-drive the yoke and throttles. This has been discussed plenty as well, and there's no inherent advantage to one way over the other.

"The irony-meter is off the charts..."

Particularly since this article is immediately followed on the page with "Baboons learn to identify words". It seems that at least some baboons haven't learned to associate sense with those words.

The cracks are in aluminum wing rib feet. Has nothing to do with composites.

"Rockets required bits of "unobtanium" during the 60s."

Not really. I don't doubt that there were some advances in high temperature materials, but jet engines were driving the same research as well. The stuff in 60's engines were nowhere near the theoretical edge that a hundred thousand kilometer long carbon fiber nanotube is.

The early rocket engine problems were mostly related to learning about injector voodoo (the F1), the physical properties of liquid hydrogen (RL10 Centaur), and understanding the bearing and sealing issues related to high powered turbopumps (any number of early engine explosions). None of these required anything like the fundamental advances in material science that an elevator will need.

Yeah, I wasn't impressed. Rockets may be inefficient, but they are a hell of a lot better than anything else we have currently -- at least, anything that doesn't require large quantities of unobtanium. Space elevators are right on the edge of what is maybe barely possible in a few years, never mind the past 50.

He does mention the key fact about getting to orbit -- the need for a massive horizontal velocity -- but it almost sounds like he doesn't really comprehend the energetics involved.

He had some valid points about payload sizing, but as far as I know that has been a non-issue for years if not decades.

I have a basement home office as well, with a leaky door. There's no point in keeping the house heat up since it doesn't help. I simply put pants on under my bathrobe in the winter. :-)

Count a +1 for pair networks. Reliable, solid, and not annoying. Their plan offerings were simple and easy to choose among, last I looked. (I picked one 11 years ago and haven't had to change.)

I have had interactions with them exactly twice, and once was them offering a constructive suggestion as to spam handling. That's the kind of provider I like, all walk and no talk.

Yeah, good luck with that. Have a second career ready?

I once consulted on a large program that had been written in as convoluted a manner as possible, with few or no comments. The guy who wrote it used to brag about "job security". Well, when the company finally allocated a budget to replace the program, they not only fired the guy, but made sure that as many people in that industry as possible knew about it. He was unable to find a new job in programming, and last I heard, he was trying to sell cars somewhere down south.

You might have job security for a while, but it's gonna catch up with you.

Filling the drive with helium should help; the speed of sound in helium is 3x higher than in air, and it offers less resistance.

(Hydrogen would be even better, but it has a tendency to interact with metals in unfortunate ways.)

A few hours a day - not every day, even, he takes a few off here and there - and a little longer on the weekends isn't excessive. Online gaming actually cut down my "lazy" activity time and cut costs. I wasn't plonked in front of the TV (cancelled a few cable packages, rented fewer DVDs), I decided to spend more non-game time away from the computer and/or TV (read a bit more, got out of the house), and on top of all that spent more time with the better half (playing the game together, chatting while we did, etc).

Yeah, sometimes you don't get to play or TV or whatever for a while, something more important is happening. We stopped playing for a few months last time we sold the house, we had work to do when we got home. Online gaming is only excessive when you fail to keep up with life's priorities (job, home, health, family, friends). Ditto any other gaming, TV time, internet surfing, hardware hacking, wood duck carving, drinking, drugs, food, jogging, etc etc etc. It's usually easy to keep it all in balance, and part of what WoW does well is deliver a game that you CAN walk away from, to focus on the important things, and still keep up with the game.

It's not so much that "Casual" gaming is influencing MMO's, as it is that game publishers recognize that a lot of gamers are all adult-like now, and if we can't integrate the game into our real lives, we're not giving them our money. And money - the market - is what influences MMO's.

People complain that legislation isn't written in English because people who don't have any legal training are still expected to be bound by it. Few people complain that patents aren't written in plain English, they complain that they are written in legalese and not in the relevant terminology for the field to which they apply. This means that they are understandable by lawyers and not by the people who would be implementing the inventions, which rather counters the point of granting patents in the first place (to encourage sharing of ideas).