I was working on an interface to a radar digitizer, and some things weren't working right. The head person on the effort was a freshly-graduated electrical engineer, whereas I had no degree but many years of hands-on experience. We hooked up a logic analyzer, and everyything looked fine. I wasn't convinced, so I hooked up an oscilloscope as well and watched the transaction that wasn't working correctly. I pointed out a signal that went from 0 volts to about 0.2 volts, then back to 0. "That's not right", I said. It should be 0 volts or around 5 volts, not some voltage in-between. The EE said that couldn't be the problem, 0.2 volts was a valid logic zero. I agreed that while it was a valid logic zero, it shouldn't be changing voltage like that. This is the sort of analog detail you can see with an oscilloscope that's hidden by a logic analyzer. I explained that normally waveforms like that show up when there's "bus contention", when one circuit is trying to pull a signal up and another circuit is trying to pull it down at the same time. For technical reasons, TTL signals like these have more strength pulling down than pulling up, so you get a lowish intermediate voltage. "That's not supposed to happen", the EE said. And he was right, it's not supposed to happen, but that is evidence that it is happening, so our next step was to figure out why. Once he'd accepted that we had a bus contention issue with that particular signal, we were able to quickly work out why it was happening and fix it.

Afterward, he admitted he'd been annoyed that I had been assigned to work with him on EE issues when I didn't have a degree, but seeing how I analyzed a problem showed him the value of real-world experience and the ability to challenge assumptions.

When I was little, maybe five or six years old, my parents took me to a psychologist? psychiatrist? I don't know. I knew I was being taken to be evaluated, but was a little unclear as to why. From my current vantage point, I realize that I was a deeply weird kid, but at the time, since I pretty much ignored other people to the extent that I could get away with it, I wasn't aware of how different I was. In any case, as part of the process, they put me in a room by myself. Again, I realize now that this was an observation room, and the conspicuous mirror all along the upper part of one wall was a one-way setup, so people could see what I would do on my own.

In the room were a bunch of things I was probably expected to go notice or play with or somesuch. But they were dumb and boring, so I ignored them. However, there was also a row of cabinets along one wall. And I got it into my head that I wanted to know what was in the cabinets. I was bored, and I hating being bored. Maybe there was something interesting in the cabinets. I tried to open one, but it wouldn't open. The logical thing to do would be to give up and maybe try one of the other cabinets. But I wasn't logical, I was annoyed. Stupid cabinet won't open? I'll make it open! I felt as if that cabinet had personally wronged me by not opening. There was no one else around (that I was aware of, anyway), so it was up to me to deal with this problem. So I started yanking at the cabinet with singleminded, raging ferocity. I was a skinny little thing, but I was determined, and focussed my entire raging intensity on this stupid cabinet that would. not. open.

Then it opened, all at once. A metal piece snapped off and clattered to the floor, and the door flew open. And, to my disappointment and chagrin, I observed three things. One, the cabinet contained nothing more than some boring papers. Two, I had broken the latch. Three, if I had tried the door next to it, it would have opened with no resistance, and I could have slid the latch over, and opened the original door with no problem.

So there I sat, in the all-too-familiar aftermath, realizing that I had broken something that was not mine, and worse, that it had been utterly unnecessary. I sheepishly hid the broken piece of latch inside the cabinet and hoped nobody would notice it until I was gone. No one said anything about it, so I figured I had gotten away with it.

Years later, I realized that they had probably been watching the entire time, and knew I had broken their cabinet.

Still more years later, I reconstructed the sequence as best I can, figuring my parents had come to them, explaining that their little boy had some emotional issues, and the mental health professionals were trying various things to try to figure out what was wrong. Well, that little episode must have given them something to chew on!

I still feel abstractly bad about breaking their cabinet lock for no real reason, but such things aren't that expensive, and I get the impression that they were being well paid for their services. I wonder if they billed my parents for that lock (my dad would have given them no end of grief if they had tried). I can't help wondering if my parents were there too, watching me flip out and break a cabinet, cringing as other people saw my antics, but secretly glad someone could see that they weren't exaggerating my fitful behaviour.

The first computer I owned capable of putting graphics on a screen was an Atari 800. Since it was built by a company known for video games, it had attachments for joysticks, paddles, and the like as well. It was a dandy platform for gaming, in its day.

Naturally, I decided to try to write my own computer games. There were several of these, but a perennial favourite among my friends was one of the simpler ones, dubbed "Kill the Cities". In this game, you would be presented with a 3 × 3 array of red and green rectangles, which were the "cities". You had a crosshair to aim with, which you could move about the screen, and push the "fire" button to shoot. You had unlimited time, unlimited ammunition, the cities didn't move, didn't have shields, and didn't shoot back. A single shot within its boundaries would destroy a city. If, under these difficult conditions, you actually managed to wipe out all the cities, the game would print out "You win! You hear that? They're CHEERING for you!", accompanied by a hissing noise.

As I wasn't yet expert at dealing with graphics, there was a bug in the game that some found more entertaining than the game itself: the crosshair would erase the cities as it moved about, so a player could eventually render all the cities invisible. This made the game even more challenging!

I was at a convention once where Insight Studios had a panel with three of their artists, Marc Hempel, Mark Wheatley, and Frank Cho. Cho was delayed, so we had these comic artists sitting up there, asking if the audience had any questions. It slowly became apparent that most of the audience had just come to see Cho, and hadn't even heard of the other artists, and nobody had any questions (other than the inevitable "how can I break into comics" one). So I decided that I essentially had the entire panel to myself, and started firing off any bizarre questions that came to mind. So I started in on Hempel, asking him "Hey, you're an inker - what are you doing with clean fingernails?" He gave me a huge grin and explained that he'd been on the road for a couple of weeks with little time for drawing and it was a big surprise to him that fingernails could be clean. Still nothing from the rest of the audience, so I went again. And again. And again. Goofy, off-the-wall stuff, and we all had a good time with it. Eventually, Cho appeared, and the audience then had plenty of questions, so I just sat back and enjoyed myself. At the autograph session afterward, the artists actually thanked me for being so entertaining and not letting the panel just languish - they also all gave me really nice drawings with their autographs!

I used to work for a computer company, and one of our customers in Jacksonville called to say our computer couldn't communicate with any of the other computers on base. The company dutifully flew me down there to troubleshoot in person. I did some tests on our computer, and everything checked out, but sure enough, it couldn't talk to any of the other computers. I asked the folks there if the other computers could talk to each other. Nope, nobody was talking to anybody. Was it possible the other computers were all broken? I asked if I could get access to the other computers. They said it was okay, and I logged in to one of them to investigate. It was misconfigured, so I reconfigured it. Sure enough, it could then talk to our computer.

I proceeded to go through the rest of the other vendors' computers, fixing them one at a time. When I was done, all of the computers could talk to all of the other computers, which caused the customer to believe that I had been right all along and the other computers had indeed been the broken ones - the ones whose own vendors had been unable to fix. Our company came off looking really good, fixing all the other vendors' computers after the other vendors had been there and simply blamed everybody else (as I too had, originally - but I had been right!).

The customer said to let them know any time I felt like a trip to Jacksonville, they'd be glad to invent a problem and request to have me come down to "fix" it.

When I was in school, and manifestly unpopular, I still enjoyed going around and taking pictures. My Polaroid One Step had a slow lense and a large image area to expose, onto slow film. It took a lot of light to make a good picture, so I had a powerful flash. Some people would object to me popping in to take random pictures, so I started telling people "It's okay, I'm with the yearbook committee." I got away with this for a while.

Until I happened across a room of pretty girls, and took their picture. The old "yearbook committee" trick of course failed, as this was the yearbook committee. Oops.

When I was a kid, we had an old tube television that occasionally had issues. One day, it started acting up, with a bonus of visible flames behind the channel indicator! So I went to the kitchen, told my mom "the TV's on fire", and went out to play.

Later, it developed that I hadn't really succeeded in getting my message across, and the TV had continued to burn for a while. It was explained to me, that when something is important, it's not only allowed, but required to distract a busy adult and get their full attention to tell them.

I was working on a contract where we were going to sell SCSI connected floppy disk drives. We got a drive in, but it didn't work, so they assigned it to me. I added in some debugging code, and it looked like the drive was wonky. The computer would send a "read" command, and the device would respond "OK". This confused the computer deeply, as it expected the drive to either return a block of data and "OK", or an error. Just responding "OK" didn't make sense. All the other devices on the bus worked just fine.

The hardware engineer on the project rented a SCSI analyzer, which also insisted the drive was misbehaving. It clearly showed the read command going out, and the "OK" status coming back. So we ordered another drive, and when it arrived, it did exactly the same thing. Monitoring other devices showed the expected behaviour: send a read command, get data, then get the OK status.

I, however, did not trust the SCSI analyzer. It operated on the assumption that everything was operating according to specifications, and was designed to show what data was going back and forth, not investigate weird protocol violations.

Accordingly, I went and rounded up a logic analyzer, which just shows the raw signals, and does not interpret them at all. It is more effort to figure out what's going on from the raw logic levels, but the logic analyzer doesn't hide anything either. And sure enough, when I puzzled out what the logic analyzer was telling me, it became clear what was happening. The computer would put the read command on the bus, one byte at a time, assert the strobe signal to indicate that the command byte was ready to read, take away the byte, and wait for the "ack" (acknowledge) signal back from the target device. And this is wrong. What it should do is leave the byte on the bus until it gets the ack back. The SCSI control chip in the computer was very simple, and did not do the signal sequencing itself, depending on its device driver to do so. And, looking at the device driver source code (fortunately, we had access to it), it showed the same sequence of events: put data on bus, assert strobe, take data away, wait for ack. So I swapped two lines in the driver, so it would put the data on the bus, assert strobe, wait for ack, and then take the data away.

And lo, the SCSI floppy disk drive started to work perfectly! The remaining question was, why did the other devices work? My theory is that the other, fancier, devices had hardware SCSI interfaces that latched the incoming command bytes immediately upon strobe, so they didn't care that the data went away immediately afterward. Whereas the floppy drive implemented its SCSI interface with a microcontroller. The strobe signal would send an interrupt to the microcontroller, which would then go read the data byte off the SCSI bus. Unfortunately, by the time it got around to it, the data was gone, and the bus terminators had pulled the data lines back to their idle state of zero. And, sure enough, a SCSI command block of all zeroes is a valid command: "test unit ready", for which the correct response is simply "OK".