Debugging a difficult problem is mentally exhausting (at least for me) because you have to concentrate hard on the likely causes while at the same time keeping your mind relaxed so that you can think of unlikely causes. Then you have to find test cases to reproduce the bug reliably and instrument the hardware or code to figure out when and where it's happening. I do get a thrill when I've figured out what subtle or stupid error caused the bug, but it's combined with anxiety that maybe it's really something else, especially if it's not completely obvious how the bug is causing the observed misbehavior. So the high-five is tentative.
So while I find debugging a (usually) satisfying challenge, it's not the part of engineering I like best and I try to design hardware and software that won't need debugging. I think of engineering as an art form: creating beautiful, elegant hardware and software and user interfaces that are a joy to work with rather than just hacking together something that seems to function properly. Many engineers share this view: Steve Wozniak talked about being an artist-engineer at his 2011 Embedded Systems Conference "fireside chat", and at a 2012 Design West forum Raspberry Pi engineer Gert van Loo said that engineering is the best way to make a good living doing art.
There's a story about the artisan who made the beaten copper doors for the Tsar of Russia. He would take a large plate of copper, and pound it with a hammer, over and over and over, creating beautiful swirling patterns. Someone asked him: "How do you know when it's finished?" He answered: "It's never finished -- I keep pounding until they take it away from me." Engineering is like that: we'd always like to make it better, but at some point they take it away so they can ship it.
@betajet, A student once asked me how I learned how to debug. I hadn't really thought about it before, but after considering the question a bit I told him it was probably the many detective novels I read as a teenager.
It makes a lot of sense that a love of detective work (as manifested by your love of the detective novel) -- and not just a love of "problem solving" -- would help explain what keeps an engineer in engineering. It must take a huge amount of patience to be an engineer. I've heard airline pilots describe their jobs as "hours of pure boredom, seconds of sheer terror." What is the electrical engineers equivalent? Hours of frustration and hard thinking, followed by seconds of high fives, then on to the next problem? I'm sure you can say it better.
Good observation about the cars in an intersection, Martin. I've also noticed that high-priced sports cars will often yield before low-cost beaters, and that they go out of their way not to park too close other cars in parking lots.
The author is correct that troubleshooting is an art.
As far as skills for a good troubleshooter for electronic circuits
Understanding there may be a mistake in the circuit design
Understanding there may be a mistake during circuit assembly
Debugging individual circuit segments
Knowing the problem may be in the components and not the circuit design
Attacking the problem from different angles
Experience knowing when your knowledge isn't enough and to call in help
Not being afraid to start over from scratch
I am a manufacturing engineer and not a circuit designer but have plenty of experience in electronics. Solving a difficult problem is about how knowledge and experience are used to create a solution. Sometimes troubleshooting is fun. The joy in solving the problem can make having the problem worth it.
When I troubleshoot, I am never afraid to make a mistake or go the wrong direction. Learning what doesn't works is just as good as learning what does.
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. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.