Having watched EEs who believe themselves to be genius* programmers in action
For this the Internet coined the phrase pair:
Beware of the programmer with a screwdriver
Beware of the electrical engineer with a text editor
The only correct way to handle computer systems today is to look at them as a river. It might be trusted to be wet, muddy, full of eels and other more generic things, but it will never be identical to last time you fell in it.
EE's tend to forget this, and regard computer systems as "dependable". That is a major fault in their thinking, where they apply the sound logic of most circuitry up to microcontroller complexity -- that it will behave predictably and only fail in obvious ways. The modern conglomerate of hardware, $DEITY knows how many opaque layers of microcode, and an operating system that's designed for word processing and very much not for embeddity things is theoretically still a machine, but it has, by sheer complexity of numbers, grown so unpredictable that it needs to be treated differently.
The latter may well be true, but the perspective I've seen it from is the one where almost all EEs writing code are self-taught, or are taught by other self taught EEs. If you're dragged up via the programming route there are things that you are explicitly taught that are
more than the things you will self-discover by writing code to get a particular job done. EEs tend to learn by trying to write code to get a particular job done - jumping from "
knows nothing" to "
has a finished working product". Taught programmers learn in little steps with critiques of increasingly more complex programming tasks given to them as feedback along the way by more experienced and better qualified programmers. If the programmer being taught makes one of the many classic errors they will get told "
Don't ever do it that way, and here is why.".
"
That way" probably works, for some value of "works", but is undesirable for any number of reasons -
some common ones being:
- computational complexity (doesn't scale to 10x, 100x or 10,000,000x as much input data),
- numerical analysis (tiny arithmetic errors accumulate to form significant, even massive, errors).
- maintainability (comprehension) - Will someone, including the original author, be able to understand this code in the future?
- maintainability (correctness) - Can you update this code without breaking it. Classic example being the "magic numbers" coding style I referred to earlier.
If someone self-teaches and gets a working program out at the end of the day, it creates a positive feedback loop. It worked, therefore it must be correct. Compare to the negative feedback loop one gets if
taught: "
Yes, this works now but is suboptimal becuase X, or will break in future because Y".
This applies to
any self-taught programmer, but is often worse with EEs because (1) there are a lot who need to produce code without formal training, (2) EEs like to tell themselves that they passed "
one of the toughest degree courses" and as a consequence can overestimate their abilities in other disciplines especially ones that
appear related like computer programming (
i.e. Highly fertile ground for the Dunning-Kruger effect.).
Home
Help
Search
Login
Register
