Re:It may be time for me to make this choice soon.
on
From Bess to Worse
·
· Score: 1
I don't have any second or third-hand experience, and I grew up before the web, but my experience was that I was completely oblivious to all sex in media and advertising until I hit puberty, at which point I immediately noticed the less subtle stuff. It was there all along, but until I started paying attention to it, it didn't exist. Sex in movies, late-night chat line advertisements on television, sexed up pop stars, laddy mags at the convenience store, all that stuff magically winked into existence when I hit puberty, and it still took me a while to assimilate it all. (I didn't notice all the sex in old movies from the '40s and '50s until I was an adult.) There are a lot of things kids don't understand about the world, and they have to ignore most of it in order not to be overwhelmed by chaos. (Just like adults, I guess....)
I hope that makes you feel a little bit better about what your kid is exposed to right now. If he's anything like I was, you have approximately three years to figure out how to handle it. Then he'll see some hardcore midget donkey scat porn, start jerking off to it, be lured to Romania by a hardcore midget donkey scat-loving pedophile, and appear on Jerry Springer blaming it all on you.
I use keyword searches because it's simpler to use the same interface for all my searches. I hit ctrl-L to put the cursor in the address box, and then:
gg foo (Google) ggg foo (Google Groups) wp foo (Wikipedia) cc foo (calorie-count.com) az foo (Amazon) dict foo (dictionary.com)
Plus you can use them for non-searches:
ym (Yahoo Mail) etc.
Using a special search function for Google which you can't use for anything else just adds extra complexity. One way for everything is simpler.
You're right in assuming the purpose of this paper is to support a project -- it's RAMP, and it's actually pretty cool. Rather than trying to solve all architectural issues up front and putting all the eggs into one architectural basket, RAMP aims to use reconfigurable hardware to prototype many different parallel architectures to see which ones can be efficiently programmed. This is a much more software-friendly approach than has been tried in the past.
The thing is, MOST algorithms cannot be PARALLELIZED or it is not worth it.
That's the theoretical problem. The practical problem is that a large amount of low-hanging parallelization is thrown away because current languages and architectures force (or strongly encourage) programmers to unnecessary sequentialize their programs, even when they know that their code contains potentially parallel constructs. Plus, the frameworks for specifying parallelization are nonstandard, nonportable, designed with specific hardware architectures in mind, and can't be composed with each other.
Yet the best baseball players in the world make errors every season (on how many throws? what error rate is that?) and rarely, if ever, make an optimal throw. Even pitchers, the best and most specialized throwers in the world, can't throw each pitch exactly as they intend, despite a lifetime of practice using the same ball at the same distance.
Plus, if you ask them to throw a zucchini accurately, they'll suck until they've had a few hours of practice.
Nobody has tried to make parallel programming accessible except the people who are already good at it, and the people who are already good at it are trying to help everyone else follow the path they took, which is to understand it mathematically. Unfortunately, the vast majority of programmers are not mathematically inclined at all. (Anal retentive + antisocial != mathematical.)
Imperative programming gives people a native, intuitive way of solving problems. Everyone knows how to give directions for performing a task, and it's easy to imagine the computer following your directions. With a little bit of effort on everyone's part, I think a similar concrete metaphor could be created that would allow average programmers to specify a significant amount of parallelization in their programs. For instance, managing a group of workers in a bakery. The work to be done can be thought of as a collection of tasks (single-threaded imperative programs). Each task may depend on others tasks. (E.g., you can't mold the cookies until you've mixed the cookie dough.) The bakery model even gives you a concrete illustration of resource sharing, though I think it would be unwise to allow programmers to manage resources -- the framework should handle resources and make deadlock impossible.
A mathematically inclined person may see these kinds of metaphor-based frameworks as conceptual straightjackets, and they're right. A framework boxes you into one way of specifying parallelism, which may be inefficient or unnecessarily complicated for many problems. I think it's a step forward, though. People who are capable of thinking more abstractly won't be mentally crippled by learning one limited form of parallelism -- they will still be able to learn more sophisticated approaches -- and people who aren't that capable will at least be able to take part and derive a limited benefit.
Thanks for clarifying. It changes everything to know you were asking for specific information that Dell should have been able to provide. As the AC said, you should update the Consumerist story so it's clear you weren't just calling to vent.
BTW, your insurance company might be helpful in getting the information, if they don't have it already. If Dell is in some way obligated to give up the information, your insurance company will know how to trigger that obligation. They'll tell you exactly who to call, what to say, and what information to have on hand. (If Dell isn't obligated to give up the information, it's good to know that so you can give up calling and pursue the PR angle.)
Don't the people that answer the phone have away to escelate something like this?
It sounds like he got escalated multiple times. But what could they do for him? Any company will route you to someone who will take down a complaint. ("I'd like to make a complaint" has never failed for me.) But that's not what he wanted to do. Any company will route you to the legal department if you have something legal to say... but he didn't. He didn't want to initiate any official process, because he's quite sensibly going to leave that to his insurance company and possibly his lawyer, if it comes to that.
In fact, he says he only wanted to "notify" them of his "problems," which he was surely able to do. It only takes thirty seconds to tell the story, so he probably "notified" half the people he talked to. There's no explanation of why he kept calling, who he was trying to reach, or what kind of satisfaction he wanted from them.
So what should Dell have done? Transfer him to the legal department -- no, he wasn't calling with any legal business. (He was probably offered the option anyway.) Let him tell his tale to a non-lawyer -- fine, he did. Have a non-lawyer discuss or even acknowledge what he said -- no way in hell.
Granted I don't know exactly how everything went down but the company should have been able to route the calls to the right department.
That's the point. There was no right department because there was nothing they could do for him. He can't even clearly say what it was he wanted. That's a pretty good way to get transferred around aimlessly and hung up on, especially if you get escalated to busy people who can tell you have no clear aim in calling.
Another good way to get hung up on is to badger people about something they've told you they can't discuss. Suppose you were in a car accident and the other guy kept calling you and asking to talk about his medical problems. Wouldn't you start hanging up on him?
Something like a server could relatively easily make use of almost any number of processors; one per client maybe.
What happens when a 1024-core server is too slow to handle 700 concurrent connections, and the only upgrade option is a 2048-core server? Then it matters whether each of those 700 requests is a parallelizable problem. Imagine a server that solves difficult computations like routing delivery traffic, designing tailored clothes from customer snapshots, monitoring security camera feeds at a casino, or analyzing a twenty-second voice recording to decide where to route a call. ("To help us best serve you, briefly state why you are calling.") Saying that one core per client will always be sufficient, even when cores stop getting faster, is tantamount to saying that nobody will ever figure out how to use all that power -- historically, a poor prediction.
Bah, this has nothing to do with looking out for his interests and getting fair compensation for his loss. His homeowner's insurance company is already handling it, and if he wants to recover damages not covered by his insurance, he knows the next step is to call a lawyer, not Dell.
So, if he knows this (and I think it's safe to assume he does), why is he calling Dell? A house burning down is not like a hard drive dying. Calling them on and the phone and expecting to have a casual chat about a matter relating to insurance claims and possible legal action is asinine and simply obnoxious. "Notify" them? Gimme a break. No wonder they hung up on him. It's the only safe thing to do when a guy calls you repeatedly and fishes for comments about an issue that may be discussed in court.
I'm sure the guy is taking appropriate steps to protect his interests. This stuff about calling Dell is nothing but entertainment; it's completely irrelevant to resolving the matter, and he knows it. He's just wasting their time and trying to embarrass them.
Maybe you have to go to prison if you can't pay, like a debtor's prison. If so, it's more evidence that Russia went straight from communist industrialism to 19th-century Dickensian industrialism.
The Russian attitude seems to be, "Socialism, capitalism, who cares? As long as everyone is miserable and oppressed except for a few obscenely powerful big shots, then Russia is strong like bull and will survive in this nasty world."
Why not? If someone clearly doesn't realise something is a crime, and there's no way for them to know, why treat them as though they are evil?
Evil != criminal.
Trying to unite the two concepts leads to distrust, acrimony, and distraction from important issues. (Unfortunately, it's also the only reason most people are interested in politics at all, at least in the absence of war and famine.)
Change "evil" to "criminal" and you have a point that deserves an answer. I'm inclined to agree with you, though different aspects of law might need exceptions to avoid giving criminals carte blanche.
Searching for source code mainly helps people who want to learn programming.
Ugh.... That makes me sick just thinking about it. Because there is no hyperlinking, there is no way to build human quality judgments into the search. The search results will be of average quality, which is poor.
That means that programmers with good taste will refuse to wade through the sludge returned by code searches. They will much prefer to wade through lots of good, irrelevant code looking for something relevant than to wade through lots of bad, relevant code looking for something good.
The availability of code search tools will have no significant consequences, because programmers who do who prefer to use code search tools instead of the alternatives (books, documentation, and carefully selected examples from high-quality open source projects) will produce very little of value. Talented programmers would stunt their growth by immersing themselves in mediocrity -- but they won't consent to do so. Average programmers produce code at a much lower level of quality than the resources they use, so average programmers using other average programmers as resources will devolve into helpless, useless idiots.
Of course nothing so dramatic ever happens. People will quickly learn to ignore these tools and keep using their current methods.
You're right, but there's more to it
on
Finding New Code
·
· Score: 1
The origin of "hacking your own" starts with the most characteristic aspect of software development: unfamiliarity with the task and ignorance of the parts needed. Developers start with a small, limited idea of what they need and can't afford to sink a bunch of time into learning a large library or framework which might not suit their purposes. At this point, they're often accused of laziness. "You know you need to log stuff, so just download a logging library and use it." Yet it's too soon to do that because you don't know what features you need, or even whether you need a logging library at all. I've seen very sophisticated scientific programs that just use stdout and stderr. So in the beginning, it makes sense to just implement the bits of functionality they know they need, so they can put off the decision until they have a decent shot at getting it right.
After a bit of hacking around on a functional area, they have a rough idea what that part of the program needs to do. This is the point where things go awry. The sensible next step is to draw up a rough list of requirements, find and evaluate the existing libraries or frameworks, and choose one to replace the current code and fill future needs. Unfortunately, there are strong irrational factors that push against this.
Failure to budget time (officially, in an organized project; emotionally, for an amateur effort) for this step makes it seem like a setback that must be avoided.
Fallacious thinking about "sunk costs" creates an artificial incentive to continue developing one's own implementation.
Bosses may see the abandoned implementation as a failure instead of a prototype.
Switching from custom code to another library requires rewriting some existing code (a somewhat rational reason, but in practice usually overblown.)
And the ultimate reason:
Ego attachment to one's own code makes it hard to throw it away.
People are proud of their code and proud of their unique style. They have a visceral aversion to replacing their unique conception of the problem with a standard approach. (It would be a shame if everyone threw away their unique approach; after all, we always need diversity and new approaches. But there's a difference between making a serious attempt to create something new and inventing excuses to cling to every bit of one's creative output.)
As a result of one or more of these pressures, the experimental implementation often hangs around, keeps growing, starts to look very much like previously existing libraries (as developers borrow ideas and come to convergent conclusions), and imposes high support overhead. Learning to use an existing, mature implementation of the functionality you want (or similar functionality) should be a prerequisite for making a serious attempt at creating a full-fledged alternative.
I just ran across an excellent example of the advantage of historical perspective. This is from an ACM Queue interview with Peter Hofstee, the Chief Scientist for IBM's Cell processor program:
You know, some of the very old compilers sometimes know how to deal with this, but the more modern compilers have to learn and re-learn some of these things.... [W]hen the microprocessor was introduced, yes, system memory was only a few cycles away, and a demand-driven model of going after that memory and bringing data in that you needed was fine. The model that we have with Cell, which is more of a shopping list type of approach and you go out and you get the things that you need before you operate on them, is actually similar to what you had in the very early days, where also you may have had your main store on a spinning drum or something like that. And at that time, your processing capability, though much much much lower than it is today, was also significantly faster than your data store. So some of the techniques that people had to deal with those kinds of systems actually indeed come back into relevance right now, which is very interesting.
The University of Illinois lets you get a mini-Master's degree online. They call it a "Master of Computer Science" degree to differentiate it from their traditional Masters, which is called "Master of Science in computer science." The online degree is inferior because it doesn't require seminar work or a master's thesis, but the coursework is the same.
It sounds like you were trying to turn a shallow treatment in an intro class into something more interesting. If you already understand the material, just sit in the back, read a book, and let the professor teach. If that chafes too much, look for a school where you can bypass prerequisites. Some private schools allow that, and some public schools have honors programs that allow it.
If you make so much more doing routine programming, you must have valuable knowledge of a certain domain. I bet there are more demanding programming jobs in that domain; it just isn't obvious where they are. Maybe you should look for an entry-level job with a consulting firm that services your industry. Consulting is a lucrative and flexible gig for experienced guys with domain knowledge, solid CS skills, and a high tolerance for boredom. All you lack is high-level experience.
You should tell the PhDs to leave before they forget that they're actually good at something. And they really are. It's a failure of them, you, and your company that they spend their days doing something they suck at.
Classes in operating systems, artificial intelligence, distributed systems, and computer architecture are half about history. You find out which problems are solved, the known solutions for them, and which problems seem easy at first glance but have resisted the efforts of brilliant people for decades. You see how the stock of an idea rises and falls depending on how it relates to the current situation.
When you have complete knowledge of the system you're working in, you can rely on the basic analytical techniques taught in all scientific disciplines. Most often, though, you have a complete understanding of limited parts of the system and have to rely on instincts and guesswork for the rest. That's when a knowledge of history comes in handy, if only to help you generate a list of things that could go wrong. A basic background in CS also helps avoid the situation where you get carried away with an awesome "new" idea you just thought up that has actually been around for twenty years. Spending your time rediscovering the limitations of a twenty-year-old idea is fun, but basically a waste of time. There are enough unsolved problems that you can cheat on the solved problems without worrying that computing will be too easy:-)
(Note that I'm not saying you should skip the problem sets. Quite the opposite! The problem sets are designed to impart skills and knowledge, not artificially slow you down.)
Both the applied classes and the theory classes teach you a standard vocabulary that makes it much easier to communicate your ideas to people who share that vocabulary.
... assuming that users aren't allowed to install software. That wouldn't be a suitable rule for labs and academic workplaces. For situations where you can forbid users from installing software, the reliability problem has been faced down by big businesses and is well in hand.
It starts with the fact that for many business applications, being dependent on a central server is unavoidable. My girlfriend works in accounting for a Fortune 500 company, and when access to the central accounting system goes down -- most often because network security configuration gets jacked up -- nobody in the accounting department gets much work done.
Needless to say, a great deal of expertise and technology has been developed to minimize those occurrences. It only happens a few hours every year, maybe the equivalent of one or two working days. That's less than 1% downtime for an application that depends on at least three servers: the network authentication server, the accounting system, and the network application server.
It doesn't take much savings to make 1% downtime worth it. (Who knows if it scales down economically to small installations, though.)
Watching professional poker on TV is like sitting in a coffeehouse reading Finnegan's Wake. You get to enjoy a pleasant fantasy of being smart enough to appreciate it, and people who see you might assume you really are that smart.
Moore's Law says that massive improvements ARE progress as usual, but people have been so pessimistic about the future of Moore's Law that giving it a new lease on life counts as a major breakthrough.
Slashdot Mirror
I don't have any second or third-hand experience, and I grew up before the web, but my experience was that I was completely oblivious to all sex in media and advertising until I hit puberty, at which point I immediately noticed the less subtle stuff. It was there all along, but until I started paying attention to it, it didn't exist. Sex in movies, late-night chat line advertisements on television, sexed up pop stars, laddy mags at the convenience store, all that stuff magically winked into existence when I hit puberty, and it still took me a while to assimilate it all. (I didn't notice all the sex in old movies from the '40s and '50s until I was an adult.) There are a lot of things kids don't understand about the world, and they have to ignore most of it in order not to be overwhelmed by chaos. (Just like adults, I guess....)
I hope that makes you feel a little bit better about what your kid is exposed to right now. If he's anything like I was, you have approximately three years to figure out how to handle it. Then he'll see some hardcore midget donkey scat porn, start jerking off to it, be lured to Romania by a hardcore midget donkey scat-loving pedophile, and appear on Jerry Springer blaming it all on you.
I use keyword searches because it's simpler to use the same interface for all my searches. I hit ctrl-L to put the cursor in the address box, and then:
gg foo (Google)
ggg foo (Google Groups)
wp foo (Wikipedia)
cc foo (calorie-count.com)
az foo (Amazon)
dict foo (dictionary.com)
Plus you can use them for non-searches:
ym (Yahoo Mail)
etc.
Using a special search function for Google which you can't use for anything else just adds extra complexity. One way for everything is simpler.
That's the theoretical problem. The practical problem is that a large amount of low-hanging parallelization is thrown away because current languages and architectures force (or strongly encourage) programmers to unnecessary sequentialize their programs, even when they know that their code contains potentially parallel constructs. Plus, the frameworks for specifying parallelization are nonstandard, nonportable, designed with specific hardware architectures in mind, and can't be composed with each other.
Yet the best baseball players in the world make errors every season (on how many throws? what error rate is that?) and rarely, if ever, make an optimal throw. Even pitchers, the best and most specialized throwers in the world, can't throw each pitch exactly as they intend, despite a lifetime of practice using the same ball at the same distance.
Plus, if you ask them to throw a zucchini accurately, they'll suck until they've had a few hours of practice.
Nobody has tried to make parallel programming accessible except the people who are already good at it, and the people who are already good at it are trying to help everyone else follow the path they took, which is to understand it mathematically. Unfortunately, the vast majority of programmers are not mathematically inclined at all. (Anal retentive + antisocial != mathematical.)
Imperative programming gives people a native, intuitive way of solving problems. Everyone knows how to give directions for performing a task, and it's easy to imagine the computer following your directions. With a little bit of effort on everyone's part, I think a similar concrete metaphor could be created that would allow average programmers to specify a significant amount of parallelization in their programs. For instance, managing a group of workers in a bakery. The work to be done can be thought of as a collection of tasks (single-threaded imperative programs). Each task may depend on others tasks. (E.g., you can't mold the cookies until you've mixed the cookie dough.) The bakery model even gives you a concrete illustration of resource sharing, though I think it would be unwise to allow programmers to manage resources -- the framework should handle resources and make deadlock impossible.
A mathematically inclined person may see these kinds of metaphor-based frameworks as conceptual straightjackets, and they're right. A framework boxes you into one way of specifying parallelism, which may be inefficient or unnecessarily complicated for many problems. I think it's a step forward, though. People who are capable of thinking more abstractly won't be mentally crippled by learning one limited form of parallelism -- they will still be able to learn more sophisticated approaches -- and people who aren't that capable will at least be able to take part and derive a limited benefit.
Thanks for clarifying. It changes everything to know you were asking for specific information that Dell should have been able to provide. As the AC said, you should update the Consumerist story so it's clear you weren't just calling to vent.
BTW, your insurance company might be helpful in getting the information, if they don't have it already. If Dell is in some way obligated to give up the information, your insurance company will know how to trigger that obligation. They'll tell you exactly who to call, what to say, and what information to have on hand. (If Dell isn't obligated to give up the information, it's good to know that so you can give up calling and pursue the PR angle.)
It sounds like he got escalated multiple times. But what could they do for him? Any company will route you to someone who will take down a complaint. ("I'd like to make a complaint" has never failed for me.) But that's not what he wanted to do. Any company will route you to the legal department if you have something legal to say... but he didn't. He didn't want to initiate any official process, because he's quite sensibly going to leave that to his insurance company and possibly his lawyer, if it comes to that.
In fact, he says he only wanted to "notify" them of his "problems," which he was surely able to do. It only takes thirty seconds to tell the story, so he probably "notified" half the people he talked to. There's no explanation of why he kept calling, who he was trying to reach, or what kind of satisfaction he wanted from them.
So what should Dell have done? Transfer him to the legal department -- no, he wasn't calling with any legal business. (He was probably offered the option anyway.) Let him tell his tale to a non-lawyer -- fine, he did. Have a non-lawyer discuss or even acknowledge what he said -- no way in hell.
That's the point. There was no right department because there was nothing they could do for him. He can't even clearly say what it was he wanted. That's a pretty good way to get transferred around aimlessly and hung up on, especially if you get escalated to busy people who can tell you have no clear aim in calling.
Another good way to get hung up on is to badger people about something they've told you they can't discuss. Suppose you were in a car accident and the other guy kept calling you and asking to talk about his medical problems. Wouldn't you start hanging up on him?
What happens when a 1024-core server is too slow to handle 700 concurrent connections, and the only upgrade option is a 2048-core server? Then it matters whether each of those 700 requests is a parallelizable problem. Imagine a server that solves difficult computations like routing delivery traffic, designing tailored clothes from customer snapshots, monitoring security camera feeds at a casino, or analyzing a twenty-second voice recording to decide where to route a call. ("To help us best serve you, briefly state why you are calling.") Saying that one core per client will always be sufficient, even when cores stop getting faster, is tantamount to saying that nobody will ever figure out how to use all that power -- historically, a poor prediction.
Bah, this has nothing to do with looking out for his interests and getting fair compensation for his loss. His homeowner's insurance company is already handling it, and if he wants to recover damages not covered by his insurance, he knows the next step is to call a lawyer, not Dell.
So, if he knows this (and I think it's safe to assume he does), why is he calling Dell? A house burning down is not like a hard drive dying. Calling them on and the phone and expecting to have a casual chat about a matter relating to insurance claims and possible legal action is asinine and simply obnoxious. "Notify" them? Gimme a break. No wonder they hung up on him. It's the only safe thing to do when a guy calls you repeatedly and fishes for comments about an issue that may be discussed in court.
I'm sure the guy is taking appropriate steps to protect his interests. This stuff about calling Dell is nothing but entertainment; it's completely irrelevant to resolving the matter, and he knows it. He's just wasting their time and trying to embarrass them.
Maybe you have to go to prison if you can't pay, like a debtor's prison. If so, it's more evidence that Russia went straight from communist industrialism to 19th-century Dickensian industrialism.
The Russian attitude seems to be, "Socialism, capitalism, who cares? As long as everyone is miserable and oppressed except for a few obscenely powerful big shots, then Russia is strong like bull and will survive in this nasty world."
Evil != criminal.
Trying to unite the two concepts leads to distrust, acrimony, and distraction from important issues. (Unfortunately, it's also the only reason most people are interested in politics at all, at least in the absence of war and famine.)
Change "evil" to "criminal" and you have a point that deserves an answer. I'm inclined to agree with you, though different aspects of law might need exceptions to avoid giving criminals carte blanche.
Ugh.... That makes me sick just thinking about it. Because there is no hyperlinking, there is no way to build human quality judgments into the search. The search results will be of average quality, which is poor.
That means that programmers with good taste will refuse to wade through the sludge returned by code searches. They will much prefer to wade through lots of good, irrelevant code looking for something relevant than to wade through lots of bad, relevant code looking for something good.
The availability of code search tools will have no significant consequences, because programmers who do who prefer to use code search tools instead of the alternatives (books, documentation, and carefully selected examples from high-quality open source projects) will produce very little of value. Talented programmers would stunt their growth by immersing themselves in mediocrity -- but they won't consent to do so. Average programmers produce code at a much lower level of quality than the resources they use, so average programmers using other average programmers as resources will devolve into helpless, useless idiots.
Of course nothing so dramatic ever happens. People will quickly learn to ignore these tools and keep using their current methods.
After a bit of hacking around on a functional area, they have a rough idea what that part of the program needs to do. This is the point where things go awry. The sensible next step is to draw up a rough list of requirements, find and evaluate the existing libraries or frameworks, and choose one to replace the current code and fill future needs. Unfortunately, there are strong irrational factors that push against this.
And the ultimate reason:
People are proud of their code and proud of their unique style. They have a visceral aversion to replacing their unique conception of the problem with a standard approach. (It would be a shame if everyone threw away their unique approach; after all, we always need diversity and new approaches. But there's a difference between making a serious attempt to create something new and inventing excuses to cling to every bit of one's creative output.)
As a result of one or more of these pressures, the experimental implementation often hangs around, keeps growing, starts to look very much like previously existing libraries (as developers borrow ideas and come to convergent conclusions), and imposes high support overhead. Learning to use an existing, mature implementation of the functionality you want (or similar functionality) should be a prerequisite for making a serious attempt at creating a full-fledged alternative.
So can we sue the makers of Duke Nukem Forever?
The University of Illinois lets you get a mini-Master's degree online. They call it a "Master of Computer Science" degree to differentiate it from their traditional Masters, which is called "Master of Science in computer science." The online degree is inferior because it doesn't require seminar work or a master's thesis, but the coursework is the same.
It sounds like you were trying to turn a shallow treatment in an intro class into something more interesting. If you already understand the material, just sit in the back, read a book, and let the professor teach. If that chafes too much, look for a school where you can bypass prerequisites. Some private schools allow that, and some public schools have honors programs that allow it.
If you make so much more doing routine programming, you must have valuable knowledge of a certain domain. I bet there are more demanding programming jobs in that domain; it just isn't obvious where they are. Maybe you should look for an entry-level job with a consulting firm that services your industry. Consulting is a lucrative and flexible gig for experienced guys with domain knowledge, solid CS skills, and a high tolerance for boredom. All you lack is high-level experience.
You should tell the PhDs to leave before they forget that they're actually good at something. And they really are. It's a failure of them, you, and your company that they spend their days doing something they suck at.
When you have complete knowledge of the system you're working in, you can rely on the basic analytical techniques taught in all scientific disciplines. Most often, though, you have a complete understanding of limited parts of the system and have to rely on instincts and guesswork for the rest. That's when a knowledge of history comes in handy, if only to help you generate a list of things that could go wrong. A basic background in CS also helps avoid the situation where you get carried away with an awesome "new" idea you just thought up that has actually been around for twenty years. Spending your time rediscovering the limitations of a twenty-year-old idea is fun, but basically a waste of time. There are enough unsolved problems that you can cheat on the solved problems without worrying that computing will be too easy :-)
(Note that I'm not saying you should skip the problem sets. Quite the opposite! The problem sets are designed to impart skills and knowledge, not artificially slow you down.)
Both the applied classes and the theory classes teach you a standard vocabulary that makes it much easier to communicate your ideas to people who share that vocabulary.
If that were true, we'd all be out flirting with girls instead of fiddling with our computers and posting on Slashdot.
(Just kidding, in a yeah-but-maybe-there's-something-to-it way.)
I can't find the talk on Google Video, and now I'm all pissed off.
Kudos to Google for raising my expectations this high, I guess.
... assuming that users aren't allowed to install software. That wouldn't be a suitable rule for labs and academic workplaces. For situations where you can forbid users from installing software, the reliability problem has been faced down by big businesses and is well in hand.
It starts with the fact that for many business applications, being dependent on a central server is unavoidable. My girlfriend works in accounting for a Fortune 500 company, and when access to the central accounting system goes down -- most often because network security configuration gets jacked up -- nobody in the accounting department gets much work done.
Needless to say, a great deal of expertise and technology has been developed to minimize those occurrences. It only happens a few hours every year, maybe the equivalent of one or two working days. That's less than 1% downtime for an application that depends on at least three servers: the network authentication server, the accounting system, and the network application server.
It doesn't take much savings to make 1% downtime worth it. (Who knows if it scales down economically to small installations, though.)
Watching professional poker on TV is like sitting in a coffeehouse reading Finnegan's Wake. You get to enjoy a pleasant fantasy of being smart enough to appreciate it, and people who see you might assume you really are that smart.
Moore's Law says that massive improvements ARE progress as usual, but people have been so pessimistic about the future of Moore's Law that giving it a new lease on life counts as a major breakthrough.