Karel shared several stories from investigating issues on the .NET team, highlighting lessons learned:
1) His first serious investigation involved tracking down a hardware error that only reproduced on one machine, teaching him to always ask if an issue reproduces on multiple machines.
2) Another story showed that not all bugs need to be fixed, like a metadata format bug found after 17 years.
3) Breaking changes are a risk with any fix, as innocent changes can trigger latent bugs, especially around sensitive dates like tax deadlines.
4) Tracing techniques like TTD are invaluable for reproducing flaky, high-impact issues like a networking security bug.