ote:
Yes, but ... When I was designing stuff for production, and we started using simulation, it became obvious that the simulated schematic really had to be the same schematic that we used for production documentation; one of the incidental advantages of simulation is that if you've made a drop-off on the schematic you are simulating, the simulation doesn't work, and you want to exploit that as a form of error-checking, the two documents have to be the same.
So stuff that "doesn't matter" in the simulation should still be included in the schematic data base. It may not matter now, but ti may matter when you have to go back through the documentation, years later, to find out why the hardware you are producing doesn't meet specification any more.
Obviously.
Much less insane - they document exactly what you thought you were doing, and how you were doing it. That can be less obvious a few years later.
Not just knowing and calculating, but also documenting - so you really can build the same thing again and again.
I'm not getting much done at the moment, but nobody is paying me to do stuff, or could give a shit when I get it done. When I was getting paid, and other people were relying on me to get stuff done, I was a lot more productive - unusually productive by U.K. standards, though there were times when I wasn't producing what my manager though that I ought to be producing (because he didn't know enough about what was going on, and was unwilling to be educated).
And sometimes those few seconds aren't long enough to comprehend everything that's actually going on. It's fine as long as you really are excluding stuff that really doesn't matter, but when you get it wrong it can be difficult to unblinker yourself and recognise that something small isn't always negligible.
Unsavoury rhetorical device. You couldn't care less if it's ever going to work, but pretending to speculate about it gives you an opportunity to say something unpleasant.
-- Bill Sloman, Nijmegen