If we look at jet aircraft, wear depends on the airframe and the engines, and the airframe seems to be the number of pressurize/depressurize cycles as well as the running hours. Engines get swapped out routinely but when the airframe has enough stress it's time to retire the aircraft lest it suffer catastrophic failure. Rockets are different in scale (much greater stresses) but we can expect the failure points due to age to be those two, with the addition of one main rocket-specific failure point: cryogenic tanks.
How long each will be reliable can be established using ground-based environmental testing. Nobody has the numbers for Falcon 9R yet.
Weight vs. reusable life will become a design decision in rocket design.
Great idea! Now we all only need to agree on which language to standardize on. I'm sure that worldwide discussion will be calm, focused and productive. Please post the results here in the thread once it's been decided.
I suggest Swedish. It's just about equally well known by almost everybody in the world, so nobody is starting out with an unfair advantage. I get a lifetime gig teaching Swedish to everybody. And you get umlauts! Win-win.
Oh, and by "suggest" I of course mean "absolutely demand or I will refuse any part of this scheme".
I pretty much agree. I'm an old-time Unix and Linux user, but Unity works pretty well for me. It mostly manages to get out of the way of my work - the single most important feature of any desktop - and things such as the single menu gives me vertical space for another line or two worth of visible code.
There are some real irritants. The window/app switcher has never gotten the distinction right (and I don't think it's possible), and the quick search misses things it should find. But these are smaller irritants on a desktop that does what it should do - be invisible unless I explicitly need any of it.
"we've got monkeys that have rapidly learned to control a robotic arm using only signals from a tiny cluster electrodes in their brain,"
"rapidly" and "control" are very much relative terms in this case. And note the "in their brain" - you need to implant an electrode array to get good, reliable signals. With monkeys you can do it to half a dozen animals and hope than one or two get a fully working implant. And the array has to be working for a few months or so. With a human patient you need to get it right every time, and the array has to be viable for a decade at the very least.
Either that or manipulate things via subterfuge...
I can't get to the paper, but it doesn't actually say anywhere that the girls were uniformly better. All subjects improved their understanding of computation, but the girls as a group did significantly better.
Also, when you look at more interesting and original, less copy-pasty games, female developers and designers seem to be more common than in the industry overall.
And, if you've not figured out what I'm trying to tell you, my answer in your example would be, "Unless you want to spend two more million and spend 12 more months in development, and COMMIT to that- no."
The idiot notion of not being "negative" is fantasy that some crazy HR people came up with to whitewash over the real problems going on in a given company. You need to not just simply say, "no", but in the same vein, trying to not say no is stupid, crazy, etc. Sometimes things ***ARE*** really negative things and you can't wish/will them any other way.
Sadly, the JIT model is the only way to work in a mess like that...followed up with plans to vote with your feet.
The problem with that particular notion ("Yes, but you'd need to spend...") is that they're oftentimes NOT savvy enough to grok where you're coming from and they'll just hear the "yes" and make you try to jam 18+ months of dev effort into 6-8 months with the typical, classical, predictable failures, in spite of explanations why it just won't work with their notion. They hear "yes" followed by "wah...wah-wah...wah-wah-wah" like on Peanuts animated features when the adults talked. The "yes" means to them it's doable- the rest is irrelevant details as far as they're concerned (And, YES, I've dealt with the kind all too often and quite a bit in the last two and a half years, much to my chagrin...)
If "yes" is part of the answer when it probably ought to be a "no" or a qualified "no", then it's the wrong answer many times. Seriously. Any notions, from HR or otherwise that doesn't allow for a "no" answer from anyone other than executive management is a recipe for disaster.
They saw the cookie-cutter AS degree and passed on him. Not broad-based enough. Probably in a downturn.
Both items are deal-breakers when you're dealing with someone with the levels of experience that were available during the latter condition. (Why get a fresh AS grad, when you can get an SME for roughly the same price? Mainly because the SME's desperate...)
Yeah, you're technically old-school. You were taught a discipline- which, in truth, is little different than learning a trade, to be bluntly honest.
Colleges have lost their way...or worse, they've taken to strip-mining students for all the cash they can bleed from them and the government through student loans.
How many of them are doing embedded Linux and Android projects- and when they weren't, how many of them were using ThreadX, VxWorks, pSOS, Lynx, QNX, etc.?
If you needed to know VS, you were working in the wrong circles. I didn't need to know VS even though it was one of the bigger deals for doing Windows development- I knew how to code C++ and understood and used ATL, MFC, etc. Which, by the way, is the way everyone should've framed it. Not, "do you do VS"?