Fifteen years ago, at one of my first jobs, I fried a piece of hardware.
I slipped while inspecting a live circuit board with a voltmeter. The voltmeter probe itself conducts, and when I slipped, I accidentally connected a sensitive component to a raw, unresisted power source. Sparks flew, smoke rose, and then BOARD NO WORKIE.
For help repairing the board, I turned sheepishly to Dave, the hardware expert who sat behind me. I didn't like Dave, but that's another story.
What's interesting, and suddenly seems relevant again in my career, is the way Dave fixed it. He started removing parts and retesting the board with parts removed. He did this until the board's behavior matched his expectations given the disability that he saw. He then took the board to the manufacturing department, and asked them to replace the missing parts.
Unfortunately, that wasn't quite enough, because my accidental short-circuit also melted a trace. A trace is one of the thin wires that goes through the middle of the circuit board, it's integral to the plastic, so we couldn't just ask manufacturing to stick another one in there. Instead, Dave had to replace the trace with a hand-soldered wire which hung inelegantly off the board from then on.
Many things happened that day that I took lessons from, but the ones that seem relevant right this second are:
- Removing parts led the way to understanding the problem.
- Damaging the board ultimately revealed previously hidden information about how it worked.
These days, I stick to software for the most part.
Recently, at work, I removed a large piece of functionality from the software we make, because it's no longer supported. Doing this was VERY educational. I wish I had done it years ago, when I started at the company. The next time I start on a new project, and I need to familiarize myself with the codebase, I intend to make a secret branch, pick an arbitrary, big feature, and remove it. I recommend you do it, too. Seriously. It informs you of the greater architecture of the software in a very practical way. It might change your mind about some design decisions.