Quote from: chaotic neutral observer on March 30, 2019, 01:38:45 AM
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.
Also, when we have this mentality of "not my problem", and the problem festers and its catasthropic enough, at some point or another it becomes your problem now too :horrormirth:
No, it's not my problem then either. It's everyone else's problem!
Most of that applies to system design, as well. I'm gonna steal this and share it with my team.
Quote from: nullified on March 30, 2019, 03:22:43 AM
Also, you missed "any solution where you tack on something to handle the kinds of breakage you found will fail worse than if you had never put it there". I learned that the hard way. If something "only" fails in one specific case, bandaiding that specific case always only makes things worse.
Further, you will NEVER document why you made that change (because it was a temporary experimental fix that seemed to work right so you never did it "properly") so even if it doesn't break, it will get removed by someone who doesn't know what it does (future you, "why is this bit here?") and then everything breaks anyway. Worse, you'll be all "I fixed this though! I fixed it before! How is it back!"
Quite. Hmm, let's see:
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).
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.
Another I forgot:
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.
Quote from: The Johnny on March 30, 2019, 04:32:04 AM
Quote from: chaotic neutral observer on March 30, 2019, 01:38:45 AM
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.
Also, when we have this mentality of "not my problem", and the problem festers and its catasthropic enough, at some point or another it becomes your problem now too :horrormirth:
This is true, but I was thinking more along the line of:
Junior: dude ur crap is broken
Senior: Alack! I shall remedy this forthwith.
<time passes>Senior: The fault lies not with mine, but with thine. Behold! You have reversed the arithmetical sign.
Junior: Ffff.....
I have been on both sides of this exchange. Twice in the last week, even. The problem is, you never really know which side you're on, until you go through the motions. Assuming I'm in the wrong to start with produces a higher hilarity-to-embarrassment ratio.
Quote from: Q. G. Pennyworth on March 30, 2019, 03:32:06 PM
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. :fnord:
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.
It looks great.
Ship it.
I really appreciate the extra work redoing the numbers and tidying up before giving me the go-ahead. Looking forward to more pages from you!
These principles really fit well with how one goes about writing effective code. Though I have no experience with it myself, some of Tom Scott's videos (Single Point of Failure (ftp://youtu.be/y4GB_NDU43Q), The Consequences of Your Code (ftp://youtu.be/LZM9YdO_QKk), etc.) really bring some of these ideas to mind.
Also, if only as a caveat to perhaps #6, the philosophy "fail faster" feels mighty appropriate in situations like these.