I look at results, not what a person "looks like" while working. If I don't see good results when I expect them, I would then term that person as lazy or incompetent or needing additional direction/mentoring (or possibly having a bad hair day). Having said that, extensive experience of a person is very important in making an accurate judgement.
When asked what my personal strengths were I once told an interviewer, "I'm lazy." It definitely got his attention. Then I got to explain what that meant. I refuse to do any repetitive data work. If I can get the computer to do it, I will. In my previous job I cut data entry time by 95% and increased throughput 16-fold while eliminating data entry errors. In a still earlier job as a cost estimator I automated the cost estimating system and increased throughput 10-fold, eliminating my position which got me a promotion into engineering.
Telling the interviewer I was lazy was a gamble but it made me stand out from the other applicants and I got the job.
It could get tricky sometimes. If you have two team members, one who gets things done conventionally "the hard way" and one who got it done in an unconventional but quicker and more effective way, who should get more points? The unconventional way is often not recognized or even accepted by colleagues, more often than you'd think.
The behaviour that this article describes and recommends is not laziness, but diligence. Diligent people are careful, persistent and industrious. Lazy people are idle and negligent. To say that engineers should be lazy is either to say that they should be idle and negligent, or to redefine 'laziness' as a kind of diligence, which just a pointless muddle. So it is probably better to do away with the 'laziness as a virtue' theme.
I caution people that I am easy to get along with, except that I am sort of intolerant of two things, laziness and stupidity. I define laziness quite a bit differently, rather as an aversion to putting forth any effort to do an assigned task. That is a lot different than wanting to do it efficiently, and not need to redo it. Stupidity is refusing to expend the effort to understand something, which grows out of my definition of laziness. So you can see that we define them a bit differently. So my thinking is that good engineers want to do the job very efficiently, and only do it once, doing it right the first time.
Back before simulations were readily available and logic design was still done with discrete gates there were two types of designers - those who rushed the schematic and worried about things like timing later; and those who carefully considered prop delays, setup and hold times, fanouts, and choice of the correct family for each function based on speed requirement during the schematic drawing phase. They were much slower completing the schematic, but their designs usually worked first time. The first type invariably spent a long time debugging obvious timing problems, and their designs were always flaky in the field.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.