Wow... your years last 13 months... no wonder your math is off - I'd have gone crazy too! Such an unlucky number of months to boot...

Actually, as a "nearshore" vendor, I can honestly tell you that your problem isn't just offshoring, per-se.

Your problem is a combination of rampant and irresponsible "offshoring sales" (i.e. companies selling services they're not really up to part to deliver based solely on price which, btw, borders on dumping), ignorant management who just eats up the "price" argument thinking they can get a mercedes benz for the price of a yugo, and their disillusionment after being conned for years by incompetent IT workers charging astronomic salaries while at the same time not being worth those salaries.

Think of it: how many times have you been in a position where you are mad that you're having to clean up some incompetent slob's IT messes and wonder why they weren't let go rapidly? If your answer is "not too often at all", then I envy you. Sadly, the truth is often the opposite case.

The combination of these morons charging an arm and a leg (comparatively speaking), and management that is less than informed is fatal: even less-than-smart managers will come to the realization that it's better to get sucky labor for cheap than do it expensively. Even worse: true-blue-idiot managers think they can actually do BETTER.

Granted - sometimes they will, but this is by far the exception, not the rule, and is such a crapshoot it ain't even funny.

Bottom line: you want to keep and protect your job? Stop worrying about keeping and protecting it, and start worrying about how you can bring more value, produce more, be more efficient, etc. In the end, if you get canned for it, then you were already on the chopping block anyway and just didn't know it.

If not, then you're much more likely to be considered a valuable resource and your cost to the organization will be more than justified.

Bottom line: when an employee's value matches or outweighs their cost to the organization, the employee is a keeper regardless. Most managers - even stupid ones - think in those terms.

Well, "enormity" is a matter of perspective. 500 years ago, it required an inconceivable effort for humans to cross the atlantic in days - it took an "enormous effort" to make that trip in weeks. Nowadays, we do it in hours - and dropping. It's not unreasonable to believe that a civilization sufficiently advanced to achieve efficient interstellar travel has likewise achieved a way to do so efficiently enough that it doesn't require such an "enormous" effort from their perspective. You also preclude the possibility of advances in science that would make interstellar travel not only cheap and affordable, but fast. Thus, it would only be a matter of time before the cosmos were explored by a sufficiently advanced civilization. From that perspective is why I doubt we'd have anything to fear - those aliens would probably be more interested in studying us and our evolution than anything else. The would probably gaze in wonder and awe at us when we achieve our first true AI, or our first true means of efficient interstellar transportation much in the same way as we gaze in wonder as chimps in africa "invent" new tools to reach new food sources.

I've always been of the mentality that one should never ask of others what one isn't willing to do oneself. However, if you're a manager you're not coding anymore - you're now relegated to a support role, really. And I don't mean moral/emotional. I've been on both sides of the issue and I can tell you without a shadow of a doubt that the devs will look upon you sharing the all-nighter with some suspicion at first. But if you're smart, stay out of their way, and simply devote yourself to being their lackey with the little things so that they don't have to get distracted with them they'll appreciate it.

Brew fresh coffee. Take care of the food orders (and maybe go for special pick-up as a treat). Make sure anything that hinders their smooth progress is handled by you. Noise? Go deal with it. Something not where it should be and makes their life harder? Chase it like a rabbid dog and solve it. The best way to ensure their success (and thus cover your ass, if that's your persuasion) is to, precisely, do whatever you can to remove the obstacles to that success.

But heed the warning: if you're staying just so you can keep an eye on them, you're making a huge mistake. If you don't trust them in overtime, then you have no reason to trust them in normal work hours, and your problem is something much bigger and uglier.

Perhaps women are smart enough to realize that when they finally want to take the step into parenthood, having a "slave" IT job that requires them to be up at ungodly hours just to keep up and deal with with the lunacy that often plagues that field. Thus, they start doing the math and realize that their family is more important than being IT slaves. In those types of decisions, women are MUCH smarter than men...

I remember the days of VisualBasic, when it was billed as a means to facilitate the development of applications without requiring any real programming or software (or computer, for that matter!) expertise. I also remember what came after those days...

Simply put - though VB was "wildly successful" - but how many pieces of software built on it are still around *because they were built properly*? Most of those tools have been thrown aside because they were grossly inadequate in performance, architecture, design, etc.

I was a witness to countless fusterclucks and saw how many systems had to be re-done from scratch because some genius businessman believed what he read on the brochures only to realize that there was no such promise and now his hordes of customers were demanding delivery on the promises made. Needless to say, there were no shortage of *REAL* programmer jobs in those days :)

The problem was never with the language per-se, as I'm sure the problem won't be with Rev4. The problem was always with design, architecture, concepts, and implementation choices. As noted above by the xkcd reference, there's no substitute for clarity regardless of the tool you choose to implement your program.

I'm not knocking the tools themselves, I'm knocking the fact that they're billed as ways to "bring programming to the masses".

Just like not everyone should handle nuclear material or toxic substances or operate on a human body, not everyone should *program* computers. As such, the really big benefit I see for this kind of tool is as an end-user interface mechanism (or facilitator) - especially in conjunction with language recognition. There are some interesting ideas there that are definitely worth exploring...

I think a potential solution is a trial by a collegiate group of judges. 3 judges, 5 judges, something like that. In particular, because you eliminate the idiocy and lunacy of the jury (which, btw, I agree with your statements about them usually not being qualified to judge most "big" issues nowadays) but add a measure of counterbalance to having a single judge monopolize the decision/ruling process. By having multiple judges you essentially establish a "democracy". Fewer judges = quicker veredicts, because there is less deliberation needed. The problem then becomes: you'll need to increase the number of judges you can appoint to fill the quotas to cover all the cases that need covering - this means that you'll need to lower the standards by which judges are chosen (not that they're that high anyway... or maybe they are... I don't know :) ). You can see a pattern starting to form. However - in this approach you might have panels of judges that are experts (experienced? well versed? have a clue?) on specific topics. I.e. patent judges, murder judges, fraud and finance judges, etc. And maybe *THAT* will help a little more since now you're not being judged by ignorant people, but instead by people who would presumably be truly qualified or at least substantially qualified to judge the matter. Complex cases would bring in judges with different "specialties", etc. If more opinions are needed, the judges might even consult amongst each other for counsel - there are plenty of technological tools around for that kind of efficient collaboration nowadays. The problem of "jury of your peers" is that nowadays it often becomes difficult to find unbiased jurors or jurors that haven't heard about the case (i.e. might have pre-formed notions - don't recall what the legal term for that is). The information bombardment is constant and usually, the people less "connected" if you will are usually also less competent to judge the matter. Ironically, they would be the most attractive as potential jurors because of lack of bias. If none of the above works, I think we should fall back to that oldie but goodie: off with their heads!!