Even though engineering is commonly associated with cold scientific laws and rigid technical rules, often it has to do with creativity and fantasy as well. This is very true in the embedded systems engineering, in particular, the field in which I currently work.

All Electronics and Software Engineers know that most of the time our job consists of debugging, instead of designing and implementing. To put it simply, debugging means to find out and to fix defects that prevent a system (it being either a piece of software or a hardware circuit) from working. Commonly, this process is known as troubleshooting. Young engineers learn pretty soon that it often turns out to be harder than designing and implementing.

Surprisingly, there are no academic courses that teach troubleshooting, nevertheless it is important during the professional career of an engineer working in the ICT world. Probably, it is the nature of this process that makes it impossible to formalize it for teaching. It is not by chance, in fact, that people often refer to it by using the expression “art of troubleshooting”.

I really like this expression because it underlines the importance of the creative component which does not follow rigid schemes and predetermined rules. Every engineer should have the capability to combine such creativity with a solid technical/scientific education. The origin of the word engineer itself (Latin ingenium) says that. In fact, it means the combination of the creative capability with the ability to put the ideas into practice.

There isn’tand there will never bea troubleshooting manual. The problems are always different and, generally, they do not follow repetitive patterns. However, I think that some general principles should be taught anyway because they are helpful to define an approach that should be used as a guideline. For instance, almost 20 years’ experience tells me that separating complex systems into smaller subsystems in order to isolate the problem is usually a good idea. Many of the young interns that I supervise in my company do not follow this approach. When they deal with a relatively complex system that is not working, they just get stuck. But it would be almost impossible for anybody to find out where the problem is if the system is considered as a whole. So I suggest to them to break it into smaller pieces and to verify each one separately.

I think that the art of troubleshooting is partially an innate talent. As such, it can be improved with practice and experience to some extent. That’s why I am in favor of new forms of tests in technical schools and engineering courses: instead of answering tons of multiple-choice questions, the students should be given a system not working properly and the teacher should evaluate how they try to identify and solve the problem causing the malfunction. Consequently, the students would train for the exams by trying to solve this kind of problem. If repeated consistently throughout their courses, this approach would be very valuable to enhance their education as technicians or engineers.