featured in #453
A Systematic Approach To Debugging
- Nicole Tietz-Sokolskaya tl;dr: Nicole’s process involves six steps, each of which she expands on: (1) Identifying the symptoms. (2) Reproducing the bug. (3) Understanding the systems. (4) Forming a hypothesis about the bug's location. Instead of randomly searching through the code, the author suggests forming a hypothesis about where the bug might be located. This narrows down the search and makes the debugging process more efficient. (5) Testing the hypothesis. (6) Fixing the bug. "If you don't understand the bug behavior, you have no hope of knowing if you've fixed it or not."featured in #448
Invariants: A Better Debugger?
- Marc Brooker tl;dr: Marc emphasizes the use of invariants, conditions that must hold true during or after code execution, as a powerful debugging tool. Through examples, the author illustrates how developers can use invariants to reason about complex algorithms and distributed systems. Invariants offer a deterministic, repeatable way to understand and ensure correctness, making them a valuable alternative to traditional debuggers.featured in #437
12 Debugging Tools I Wish I Knew Earlier
- Jordan Cutler tl;dr: The first 2 are: (1) Git bisect: Run you through a binary search process between the “good commit” and the “bad commit” until it finds the commit the bug started happening. (2) “Binary search commenting”: Commenting out sections of the code and replacing it with a hardcoded value to narrow in on where the problem is.featured in #434
The Curious Case Of A Memory Leak In A Zig Program
- Krut Patel tl;dr: “This is a small exposition on an unexpected "memory leak" I encountered when writing a Zig program. We will mainly focus on a very simple allocation pattern and see how it causes a "leak" when using a particular allocator from Zig's stdlib.”featured in #399
featured in #397
featured in #395
Improve Your Debugging By Asking Broad Questions
- Hillel Wayne tl;dr: “Most of the time we ask narrow questions which are helpful when confirmed and not-helpful when rejected. If you make a lot of wrong predictions, then debugging boils down to guess-and-check. If you instead ask broad questions, you learn less when they’re true but more when they’re not. Then you iteratively close in on the actual source of the bug.”featured in #393
How A Single Line Of Code Brought Down A Half-Billion Euro Rocket Launch
- Michael Stroe tl;dr: "So what was the ultimate cause of this very short, very expensive and catastrophic flight? A line of code converting a 64-bit floating point to a signed integer, which led to an overflow passed directly to the main computer, that interpreted it as real data.”featured in #389
featured in #384