15 July 2008

(v1.1) 15+ engineering and analysis "daemons"

I offer a collection of pointers when performing design or analysis - or, as my undergraduate advisor Peter Kindlmann might've called some of them, "daemons" or background processes. These are really basic, but they've served me well. [And... with a few more from the folks from the xkcd fora.]

1. Think something's wrong? You might actually be getting the correct results! Check your intuition or understanding of the phenomenon or the device itself.
2. Don't be fooled by the barber-pole illusion. The scrolls aren't moving upwards, the ocean waves aren't exactly moving at you quite the way you think, and... you get the point.
3. Strive for maximal component utilization across timescales - within reason.
4a. Parallelize, even if it's "embarassingly parallel." Especially when technology hasn't caught up with your idea.
4b. A related point: some initially mechanical solutions evolve towards solid state.
4c. An obvious corollary: better engineers use fewer components.
4d. The "nature-made theory": the great analog circuits are tangled, interconnected, non-modular systems.
4e. Consider a genetic algorithm.
5a. The olfactory factor: smell it.
5b. My grandfather taught me that you shouldn't touch electrical circuits, but if you can't stop yourself, use the back of your hand so that if it's high-voltage you'll involuntarily seize up away from the circuit (rather than grab it).
5c. Unrelated to design, but related to prototyping: don't look into the freaking laser light. And try waving around a business card to inspect time-varying phenomena.
6. We're prone to getting the hard stuff right, and the easy stuff wrong. So:
6a. Check the interfaces, or edges, between modules.
6b. Make sure the polarities are correct.
6c. Count the parentheses and remember the semicolons.
7. Have a complete plan before sitting down at the lab bench or keyboard. Trial-and-error mode is a symptom of poor planning and a lack of understanding of your tools.
8a. Do a literature search, but don't be constrained by it. If your invention is an invention, you won't find it in there.
8b. Can your quandry be helped by cold-calling an expert?
9a. Stuck? Pretend you're explaining it to your grandma.
9b. Stuck (but getting help)? Explain the goal, not the process.
9c. Stuck (getting an idea)? Mix three usually disconnected disciplines.
10. Envision what your hero would do in the situation.
11. Use REALLY LARGE SHEETS OF PAPER. (pjk)
12. Reframe the problem with broader words. E.g. not "four-wheeled vehicle with a seat and combustion engine," but "a means of conveyance."
13. Make a real effort to spend even more time with optimistic, inventive, supportive people - or, at least spent less with in-the-box naysayers. See also dynamic optimism.
14. Meditatively construct a mental mechanical model of it - and then play with it. (E.g., if a circuit, watch current pull springy resistors down from the voltage rails. If optics, don't be afraid to use your hands in the air as virtual lenses or rays. Code up a simulation and tweak it.)
15. Deal with simple but forgettable stuff with some peripheral vision Post-Its: like this, this, or even this.

Do any of you have more?

Updated from the xkcd hardware forum (thanks: Solt, wst, and Red Hal):

16. Document what you do. What seems obvious now probably won't to you or others in the future.
17. Remember to test the obvious and bizarre use-cases.
18. Hit "save" all the time - and promote big changes to a new file.
19. Don't be afraid to sleep on it, to give your subconscious a chance to solve it for you.


g-fav

No comments: