Power dissipation and heat are generally considered system-level problems. That is, the chipmaker specifies "max power dissipation X" and the board designer has to figure out how to move that amount of heat off the part. For example, NVidia says "this will dissipate 200 Watts max," and Asus builds an appropriate cooling system. This is an area that gets neglected a lot because it's expensive to move that much heat around, and because lots of people are just bad at doing thermal design. Given a few boards with precisely the same chipset, it's very possible (likely, even) that some will fail and others have no issues.

(In other words, s/chip makers/card makers/.)

They both have jobs; they did this in their spare time.

No it's not. A clueless person can be 100% convinced that they will get ahead as a result of their actions, and just be wrong about that fact. It's not altruism that makes them clueless, it's, well, cluelessness. So yes, an altruist is clueless, but not all clueless are altruists.

I do not think that word means what you think it means.

As in, the culture of the company. I'm not a software engineer any more, I'm an electrical engineer (I worked as a coder while I was in college). In particular, I'm an analog (and sometime digital) circuit designer. I learned nothing about business practices, Six Sigma, et al in school (S.B. and M.Eng in EE and CS from MIT). Why? Because I spent all of my time taking real EE/CS classes. When I got a job in the industry, _then_ I started learning all the practical stuff I hadn't had time for in school. Why do EE companies do it this way? Because the cost of failure is so high: we spend a million dollars taping out a chip and it doesn't work because I decided to cowboy my circuit and we're out our money.

Many software companies don't see such large quantization steps in their failure cost: we lost a week here or there because the newbie's coding practices don't mesh with the rest of the team, but management is just watching their Gantt chart and we'll push on them to hit their milestone on time anyway; fuck 'em, they're just code monkeys anyway.

See the difference? The assumption that designing bad software has a small cost (mostly because it's deferred until much later when it's discovered, plus the assumption that any bug that's discovered is easy to fix) is built into the management style of the software company; the assumption that failure is extremely costly and the necessary culture of rigor are built into the management style of the EE company (well, not all EE companies... but there are shitty companies in every industry).

So why not teach EE students all about Six Sigma et cetera? Well... when? I took 5 or 6 classes a term (4 is average at MIT) and still took 6 years to do my degrees. There's just too much to cover in EE/CS to get it done---and yet there's no "cowboy issue" in my industry, as far as I can tell.

So is there really less to learn in Software Engineering? In other words, is this just a fundamental difference between EE/CS and SE? I say absolutely not. There's an incredible amount of material to cover in SE without getting into business practices: first, pretty much any CS topic is fair game for software engineering (yes, I know they're not quite the same thing). Then there are more EE-like subjects that most SE people don't get, but should: signal processing, feedback systems (yes, they exist in software just as in hardware, and they can be analyzed with the same fundamental tools). There's plenty of math to learn: discrete math, algorithms, set/group/category theory, et cetera. Then there are classes on system architecture, complexity management, and a million other really hard problems. Given all of this, and only four years to fit it all, any time spent on business practices and Six Sigma is an unmitigated waste of time. It can be learned faster and better on the job---after all, you may as well learn the business practices at the company you work for, while actually doing useful work.

Far from producing "unemployable" grads, a program with no focus at all on "business practices" will turn out coders who have wrung from college everything that ought to be learned in an academic environment, and who are ready to be apprenticed to an experienced mentor who will teach them the practical details that are dirt simple to understand.

In other words, let Vineet Nayar's coders waste their time learning about bullshit Business Practices instead of expanding their minds by learning something difficult and interesting. You need code monkeys to do shit work anyway. There's always a lowest common denominator somewhere.

Or how about this: do you think when you go interview at Google they're more likely to ask you about Six Sigma, or about problems arising in the design of a secure/anonymous/reliable distributed filesystem?

Don't forget the powerset (Kinetics Defender) that allows you to grant other people super speed and super jump, and gives the toon Siphon Speed by level 5ish. And of course, there's the utility power in the Teleport powerset that lets you teleport your allies to you! (This is extremely useful for helping low-level characters, when travelling through gigantic zones like the Shadow Shard, or for positioning the group during dangerous missions).

My kin/psy defender was my favorite toon by far. Ahh, to go back to the i4 days with no targeting limits just for a few Fulcrum Shift / Psy Wails. Brings a tear to the eye.

I work at a mixed signal IC company that is, on the digital side, principally a Verilog shop. We do have one or two projects that use VHDL, and maybe even one or two that use both. From a practical applicability point of view, Verilog is a bit more popular as far as I know, but this should not be taken to imply that you will do your students a disservice teaching them VHDL. When we interview digital designers, we don't ask them "do you know Verilog?" we ask them "do you know digital design?" The language is far far less important than the underlying concepts.

The biggest mistake you can make is concentrating on the language and expecting the programming skills will apply to digital design just because the syntax of Verilog looks like the syntax of C (or VHDL looks like Pascal, if you squint a lot). First, learn how to do digital design, then learn how to describe those designs in an HDL. Things might go slightly faster if you are familiar with the syntactic structures (i.e., C coders will feel more comfortable using Verilog), but trying to take the "do-while--if-then-else--for" mentality of a procedural coder and trying to jam it into an FPGA is going to be a painful road to failure.

It's time for a bad analogy! "Hey guys, I have a bunch of novelists whom I want to teach to write medical textbooks. Should I teach them to do it in English, or Spanish?" The answer is "whichever they're more familiar with already... but first teach them medicine."

-=rsw