Holy Nonsense?
Woo!
...er, yes. Sure, why not.
I was trying to be clever with the OP, and used BB code to construct the list, which might make cut-and-paste a bit of a pain. Below is a version with the item numbers directly in the text. I've also added a few items I've missed, which rounds it out to a nice multiple of 5.
1. If you haven't tested it, it doesn't work.
2. If you have tested it, your test coverage is inadequate. You haven't tested the part with the problems.
3. Instead of testing to prove the system works, test to prove it doesn't. You haven't succeeded until you've failed.
4. Don't be clever. Cleverly designed systems are complicated. They break easily, and are hard to repair. When you do have to be clever, pretend that a complete idiot is going to have to make changes to it later, and document accordingly. That complete idiot is a future version of yourself.
5. The key to success is the diligent application of basic principles. (see #4).
6. If it fails once, it's going to fail again. Maybe tomorrow, maybe next year, but it will happen. Turning it off and on again to make the problem go away is a temporary solution, and it will screw you over (see #8). Problems
never go away on their own.
7. There's no such thing as temporary code. There are no prototypes. Those hundred lines you hacked out for a one-time experiment? Someone will drop by, ask you how to do X, you'll give them that code as a "sample", and it's going to end up in a production system,
unaltered. That prototype board that was exposed to potentially destructive ESD as part of a test? The marketing weasel is going to send it to a customer as a "demo unit". It won't come back.
8. Tweaking things at random is a good way to find problems. It is a horrid way to fix problems. If you change something at random, and the problem goes away, do not stop investigating until you understand exactly
why your change fixed the problem.
9. The salesman is lying. If you don't know who he's lying to, he's lying to
you. If you
do know who he's lying to, he's either incompetent, or you are now his accomplice.
10. The smell of burning plastic is an invaluable diagnostic tool.
11. Assume the problem is your fault, because, 90% of the time, it is. And when it isn't, then in the process of proving it, you'll learn something by extending your investigation into the parts of the system that you aren't normally responsible for.
12. Stay on good terms with the manufacturing staff. They can do stuff you can't.
13. If it works, don't change it.
14. When in doubt, throw everything out and start again, especially the parts that work.
15. When you find the source of the problem, take the time to fix it properly. Quick-and-dirty workarounds cost more in the long run. (See #7, sometimes #14).
16. Only medium-complexity components can be documented. Low-complexity components won't be documented at all. But by the time you're done working on a high-complexity component, you will have such an in-depth knowledge of all the details and inner workings, that you can't conceive of
not being able to understand it perfectly. Even if you're aware of this, what documentation you write will be from the perspective of a mental state that you will no longer possess in a few months.
17. Study the datasheet, memorize the datasheet, follow the datasheet's instructions, but don't trust the datasheet.
18. The phenomenon you are observing is not, in fact, physically impossible. The circuit is not defying the laws of physics. The code is not violating determinism. One of your assumptions is wrong. Calm down and question everything, even the obvious.
19. You are doing it
WRONG.
20.
YOU are doing it wrong.
