Contact Us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right. 

Arch 12, Raymouth Road
London, England, SE16 2DB
United Kingdom

+44(0)7779606045

We create circuits that are both beautiful and functional
 

Blog

In defence of the "sloppy" engineer

Saar Drimer

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.