News:

Testimonial: "This board is everything that's fucking wrong with the internet"

Main Menu

Electronic Engineering

Started by chaotic neutral observer, March 30, 2019, 01:38:45 AM

Previous topic - Next topic

chaotic neutral observer


  • If you haven't tested it, it doesn't work.
  • If you have tested it, your test coverage is inadequate.  You haven't tested the part with the problems.
  • Instead of testing to prove the system works, test to prove it doesn't.  You haven't succeeded until you've failed.
  • 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.
  • The key to success is the diligent application of basic principles. (see #4).
  • 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.
  • 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 ferret is going to send it to a customer as a "demo unit".  It won't come back.
  • 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.
  • 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.
  • The smell of burning plastic is an invaluable diagnostic tool.
  • 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.
  • Stay on good terms with the manufacturing staff.  They can do stuff you can't.
  • If it works, don't change it.
  • When in doubt, throw everything out and start again, especially the parts that work.
  • You are doing it WRONG.
  • YOU are doing it wrong.
Desine fata deum flecti sperare precando.

altered

This is a guide to LIFE, not electronic engineering!

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!"

Just don't do it.
"I am that worst of all type of criminal...I cannot bring myself to do what you tell me, because you told me."

There's over 100 of us in this meat-suit. You'd think it runs like a ship, but it's more like a hundred and ten angry ghosts having an old-school QuakeWorld tournament, three people desperately trying to make sure the gamers don't go hungry or soil themselves, and the Facilities manager weeping in the corner as the garbage piles high.

The Johnny

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:
<<My image in some places, is of a monster of some kind who wants to pull a string and manipulate people. Nothing could be further from the truth. People are manipulated; I just want them to be manipulated more effectively.>>

-B.F. Skinner

altered

No, it's not my problem then either. It's everyone else's problem!
"I am that worst of all type of criminal...I cannot bring myself to do what you tell me, because you told me."

There's over 100 of us in this meat-suit. You'd think it runs like a ship, but it's more like a hundred and ten angry ghosts having an old-school QuakeWorld tournament, three people desperately trying to make sure the gamers don't go hungry or soil themselves, and the Facilities manager weeping in the corner as the garbage piles high.

LMNO

Most of that applies to system design, as well. I'm gonna steal this and share it with my team.

Q. G. Pennyworth


chaotic neutral observer

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.
Desine fata deum flecti sperare precando.

chaotic neutral observer

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.
Desine fata deum flecti sperare precando.

chaotic neutral observer

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.
Desine fata deum flecti sperare precando.

Q. G. Pennyworth


chaotic neutral observer

Desine fata deum flecti sperare precando.

altered

How does this work again?

:mittens:

Is that right? Am I doing the cool kid thing again?

Because this whole thread is mittensworthy.
"I am that worst of all type of criminal...I cannot bring myself to do what you tell me, because you told me."

There's over 100 of us in this meat-suit. You'd think it runs like a ship, but it's more like a hundred and ten angry ghosts having an old-school QuakeWorld tournament, three people desperately trying to make sure the gamers don't go hungry or soil themselves, and the Facilities manager weeping in the corner as the garbage piles high.

Q. G. Pennyworth

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!

Al Qədic

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, The Consequences of Your Code, 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.
There is no reason to,
Be ashamed of poetry. It,
Is natural. But you should,
Still do it in private,
And wash your hands afterward.

Telarus

Telarus, KSC,
.__.  Keeper of the Contradictory Cephalopod, Zenarchist Swordsman,
(0o)  Tender to the Edible Zen Garden, Ratcheting Metallic Sex Doll of The End Times,
/||\   Episkopos of the Amorphous Dreams Cabal

Join the Doll Underground! Experience the Phantasmagorical Safari!