I often say that my work is basically, most of the time, actually: Reverse engineering, finding out how stuff works, deciphering blackboxes. I refer to both software and physical systems - hydraulics - and to anything in between, control units and their logic.
Even when I was a supposed technical experts for certain (software) products what I actually did was to reverse engineer the product in question - the weekend before I demonstrated my consulting capabilities, allegedly backed up by thorough training and long-term exposure.
So I think it is worth to ponder a bit on what it means to reverse engineer.
Good-enough approach (80-20-style). I had enjoyed reverse engineering because it was different to my former life as an academic scientist. You do not need a complete theory and unassailable arguments to explain to your knowledgable peers about what goes on exactly in the blackbox. You just need to know enough to track down and solve the problem a real human being actually has. That human being might as well be yourself.
I remember the first times I solved computer problems of small business owners - based on hardly any experience and know-how, by my current standards. However, after years of exposure you might as well write an in-depth paper, but you are not forced to present your know-how in this way. You primary mode of operations is to solve problems, not to gain recognition.
Depth and breadth. It may be fashionable to say that reverse engineering certainly requires to think outside the box, and the 80-20 statement seems to imply that you don't need to bother to learn any 'theory' before embarking on a debugging venture. But if you want to become really good at troubleshooting, you better also learn the fundamentals and find a niche(s) you want to specialize in.
You focus on your specialties where you have both deep know-how and hands-on experience, and you add out-of-the box ideas related to other subjects. You stumble upon an interesting aspect and decide to learn more in depth about it. I had specialized in public key infrastructure and digital certificates, and later on heat pump systems and thermodynamics. However, when troubleshooting I might also need to learn something on-the-fly about a special CAN bus networking protocol or about heat pumps without electrical compressors.
Social engineering and no false pride. I like to work on issues that I can solve - without the need to 'escalate an issue' to some support organization in the background. However, I try to keep Geek Honor in check: You do not need to re-invent anything from scratch, and you do not need to disassemble a system in case you find the human beings who built it or at least the documentation created by them.
Social engineering can be part of reverse engineering (both terms meant in a benign way): I had social engineered my way into an organization that kept insider information like manuals or passwords, and I believe learning from your peers is an excellent way to increase your knowledge. The challenge with learning from the community is stay at eye level with your true'peers'. I had my share of encounters with suckers of know-how who only want to take but had nothing to give in return.
Against the green-field. For me, reverse engineering is strongly tied to a culture or re-use and repair, as opposed to a culture of buy and build from scratch. If you want to be creative with what is available, you need to decode the things you already have (... and after a few years of operations you might debug your own creations, no matter how excessive your documentation was.) Knowing what your gadgets do - your software, your heating system, your appliances - puts you in control.
Challenge the experts. This is closely related to the culture of re-use: If a so-called expert, certified and radiating authority tells you flat-out that this will definitely not work (often because the expert is also a supplier of new stuff he wants to sell) then you can only rely on your reverse engineering skills to prove him work.
That is perhaps the most important aspect - in our era of a growing number of interfaces with external services, clouds etc. and where you use shiny and well-sealed blackboxes that ought not to be reverse engineered at legal gunpoint.