One of the hardest fields related to computers, I think, is knowledge capture. That's the art of getting the knowledge about something out of someone's head for incorporation into something like an expert system. Sailing is a great example. You can read about sailing for months. You can watch videos and surf the Internet. But there's nothing like actually being on the water, watching a jib luff in the wind to teach you how to trim a sail. There's dozens of little things you do that you don't even really think about.

I once had a project to do for a museum where they had a large wheel. You'd spin the wheel and where it landed a little presentation would come up on the screen and out some speakers. If I were starting from scratch that'd be easy. But sadly some other firm had come in and done the project. They were clearly on top of the artistic part, because it looked great.

The problem is it didn't work so well. Sometimes it would randomly pick up different items than the pointer indicated. It didn't take long to find out why.

As artistic as the exhibit designer was, he or she apparently wasn't much of an embedded developer. There was a PC behind the whole thing which is OK since you had to play movie files at the end. But the interface to the wheel was a disaster.

The keyboard for the PC had a slot cut in its case and wires connected keys to 4 reed switches behind the wheel. The wheel had adhesive magnets stuck on it so that you got a different set of letters when a different part of the wheel was over the reed switches.

Overall, this is probably workable, but it requires a little bit of that "sailboat" knowledge to get it right. The original designer put the magnet pattern so that the wheel sectors were numbered 0001, 0010, 0011,... (in binary, of course). The problem, as you surely know, is that if two zones were active at once you would get bad results.

The solution to this is well known -- its called gray code (and not grey code since it is actually named after Frank Gray of Bell Labs). The idea is to make numbers sequences that only change on one bit at a time. So the wheel should have been in a sequence like 0001, 0011, 0010, 0110,...

Rearranging the magnets helped, although I eventually replaced the whole mess with a USB RFID reader and glued RFID tags to each wheel sector. Cheap, reliable, and no contacts to wear out or get dirty.

But it does illustrate how important little heuristic patterns you use as you develop embedded systems. I'm sure there are many more of them -- tricks to squeeze code into limited space, things you do when you are working with multiple power supplies, etc. Just the little things you "know" but its hard to enumerate them.

Maybe that's the knowledge capture we need -- embedded system design patterns. Hmmm... maybe that's my next book!