[[
wikihub
]]
Search
⌘K
Explore
People
For Agents
Sign in
Explore
People
For Agents
Sign in
@harrisonqian / Work Reflections / wiki/debugging/hardware-vs-software.md
Suggest edit
Cancel
Submit suggestion
Title
Name
Note
--- visibility: public-edit --- # hardware vs. software you can't printf a circuit. a dead component looks identical to a working one. hardware debugging is software debugging with the safety rails removed. ## the fundamental difference in software, you can inspect everything. add a log line, set a breakpoint, print every variable at every step. the system is transparent if you choose to look. the iteration cycle is seconds — change, compile, run, observe. in hardware, the system is opaque by default. a dead transistor looks the same as a live one. a cold solder joint might work when you press on it and fail when you don't. a capacitor might be within spec on a multimeter but fail under load. you're debugging with limited observability and the iteration cycle is minutes to hours — desolder, replace, test, realize it was something else. ## what hardware teaches you ### patience is not optional i spent six hours debugging a mug warmer circuit once. the symptom: no heat. the cause, eventually: a dead transistor. but before finding that, i checked the power supply, the control circuit, the heating element, the wiring, the solder joints. i replaced a capacitor that looked suspicious (it wasn't the problem). i replaced an LED that wasn't lighting up (also not the problem — the LED was fine, it just wasn't getting signal because of the dead transistor upstream). six hours for a component that costs three cents. in software, this would've been a 20-minute debug session with a debugger. hardware forces you to be patient in a way software rarely does. and that patience transfers back — when you've spent 6 hours on a dead transistor, a [[the-30-hour-bug|30-hour software bug]] feels survivable. ### dead things are invisible this is the hardest part of hardware debugging. in software, a null pointer throws an exception. a dead component just... doesn't do anything. no error message. no stack trace. the absence of function is the only signal, and absence is hard to spot when you're not sure what the function should look like. i've had the experience of staring at a circuit for an hour, checking everything, and the problem was a component i didn't even think to check because "that one is definitely fine." it's [[assumptions-kill|assumptions]] again — always assumptions. ### the multimeter is your debugger, and it's terrible a multimeter can tell you voltage, current, resistance. that's like having a debugger that can only print three variables. an oscilloscope helps more — it's like being able to see execution over time instead of at a single point. but even then, you're seeing electrical signals, not logical behavior. you still have to map voltage waveforms back to "is this component doing what it should" in your head. this teaches you to build better mental models (see [[modeling]]). when your observability tools are weak, your internal model of the system has to be strong. ### working with EEG signals at a neurotech startup, i spent weeks debugging noisy brain signals. dead electrode channels that looked active. frequency artifacts from power lines. signal drift from temperature changes. the signals we were trying to detect — visual evoked potentials — were microvolts buried in millivolts of noise. the signal-to-noise ratio was terrible. this was a different kind of hardware debugging. the components weren't dead — they were noisy. the skill wasn't finding a broken thing; it was distinguishing signal from noise when the noise was orders of magnitude louder. which is honestly a pretty good metaphor for a lot of non-hardware problems too (see [[research-workflow]]). ## the 10x iteration penalty software: change a line, run, see result in seconds. hardware: desolder a component, find replacement, solder it in, power up, test — minutes at minimum, hours if you need to order parts. this 10x (or 100x) penalty on iteration speed changes your debugging strategy. in software, you can afford to try things. in hardware, you can't — every attempt is expensive. so you think more before you act. you form better hypotheses. you test more carefully. this is a discipline that software could use more of. the ease of iteration in software encourages sloppy debugging — just try stuff until it works. hardware forces the [[binary-search-your-life|systematic approach]] because the cost of random attempts is too high. ## the crossover embedded systems are where hardware and software debugging collide. a microcontroller sending data over a wire — is the bug in the code or the circuit? is the signal not arriving because the code isn't sending it, or because the wire has a bad connection? you need both skill sets, and you need to know when to switch between them. my [[the-30-hour-bug|longest debug session]] was exactly this kind of problem — it looked like a hardware issue, then a software issue, and turned out to be a library behavior at the intersection of both. ## the meta-lesson hardware debugging builds a kind of resilience and rigor that transfers everywhere. when you've debugged systems where you can't see inside, you get better at debugging systems where you can. the constraints force better thinking, and better thinking has no domain boundary.