He Who Kills Sequents

One slightly odd thing yesterday was walking down the main corridor and thinking "the back of that bloke-in-suit's head looks quite familiar" and it turning out indeed to be The-Destroyer-Of-Sequents. It was good to see him again, of course - he'd just been speaking to the informatics bods who may recruit him, so we spent ten minutes over tea catching up before he chatted to the personnel bods. Best wishes and good luck to him, obviously.
Indeed. A youthful indiscretion, merely. He didn't make a habit of it.
The thing was, he didn't realise at first that it was his program that had brought the entire, huge Sequent shared by the whole department and all the students to a crashing halt, requiring Sequent engineers and replacement hardware. He just thought it had happened to crash during his testing. In fact, he didn't realise it until he ran it a second time.
If you can damage hardware with program then either a) there's something wrong with the hardware or b) it's a damned impressive program.

Or possibly both. And I suppose I should exclude firmware from the definition of "program". And in fact it's probably the firmware that there's something wrong with, rather than the hardware.

Or something.
He was doing extremely funky things with accessing shared memory. My guess is that he created a condition the designers had never dreamed of in which two controllers fight to assert a shared bus into two different states, causing a short and destroying a chip or two. AFAIK he didn't even need root privs to do it.

In school the best way we knew of to destroy hardware from software was to "buzz" the relay in the tape controller on the BBC Micro until it broke.
Or the traditional 'walking' HDD which would jump across a table - and eventually fall off the edge - propelled by carefully orchestrated head movements.