In defence of the "sloppy" engineer
When things go wrong it's tempting to blame the "sloppy, incompetent" engineer. Security breach? Bad board? Cumbersome UI? Ah, it's that stupid engineer again! Not the overbearing boss, lack of resources, inappropriate tools, non-existent training and mentorship, shortage of staff, impossible schedule, or ignorant management. It's that pesky sloppy engineer that's responsible for that voting machine fiasco.
That kind of language really presses my buttons. The latest press was on the thread about my engineer's emergency business card over on Hacker News where " In summary, even the best tools won't help a sloppy designer" was used to excuse unfit-for-purpose EDA tools by blaming the engineer. This isn't right and is not leading us to a better situation. (The specific comment and my response are here.)
The engineering tools we use are crap -- if that sounds a bit crass, it's because 'crap' captures the essence of the experience better than any other word I can think of. They look like a Windows 95 space shuttle cockpit, overwhelming, do not present information in an effective way, often do not check for what really matters, and stand in the way of good design practices that would help less experienced engineers. If you are forced to use these tools -- and you are because there's no other choice -- and are inexperienced, are you necessarily "sloppy"?
Instead of saying "read the thousands of warning and info messages from an FPGA design build" ask "why is the tool not smart enough to show me what's really important?". Instead of saying "make sure that the 5 V net is named the same across the entire design by clicking every segment" ask "why isn't the tool smart enough to figure out that those nets are connected, or display a small warning on the schematics instead of hiding it behind a click-wall and hundreds of other entries?". Instead of saying " print out the design 1:1 and lay the components on the paper to make sure the dimensions are OK" ask "why can't the software compare those dimensions against the datasheet?" (More about this one here).
There's a "get on with it" mentality in engineering culture, which is great -- it makes us crafty and innovative. But there's also a certain kind of unexplained acceptance of inadequate tools that might stem from that need for tinkering. "My EDA tool is morbidly broken, so I'm going to happily fix it with a script" can get our juices flowing. But this doesn’t mean that we do not deserve better, and it certainly doesn't mean that (inexperienced) engineers using current tools are "sloppy". Let's not go there please.
That kind of language really presses my buttons. The latest press was on the thread about my engineer's emergency business card over on Hacker News where " In summary, even the best tools won't help a sloppy designer" was used to excuse unfit-for-purpose EDA tools by blaming the engineer. This isn't right and is not leading us to a better situation. (The specific comment and my response are here.)
The engineering tools we use are crap -- if that sounds a bit crass, it's because 'crap' captures the essence of the experience better than any other word I can think of. They look like a Windows 95 space shuttle cockpit, overwhelming, do not present information in an effective way, often do not check for what really matters, and stand in the way of good design practices that would help less experienced engineers. If you are forced to use these tools -- and you are because there's no other choice -- and are inexperienced, are you necessarily "sloppy"?
Instead of saying "read the thousands of warning and info messages from an FPGA design build" ask "why is the tool not smart enough to show me what's really important?". Instead of saying "make sure that the 5 V net is named the same across the entire design by clicking every segment" ask "why isn't the tool smart enough to figure out that those nets are connected, or display a small warning on the schematics instead of hiding it behind a click-wall and hundreds of other entries?". Instead of saying " print out the design 1:1 and lay the components on the paper to make sure the dimensions are OK" ask "why can't the software compare those dimensions against the datasheet?" (More about this one here).
There's a "get on with it" mentality in engineering culture, which is great -- it makes us crafty and innovative. But there's also a certain kind of unexplained acceptance of inadequate tools that might stem from that need for tinkering. "My EDA tool is morbidly broken, so I'm going to happily fix it with a script" can get our juices flowing. But this doesn’t mean that we do not deserve better, and it certainly doesn't mean that (inexperienced) engineers using current tools are "sloppy". Let's not go there please.