When you hit an intermittent bug that won't reproduce, spend time building a reliable test case first. That testable situation beats writing trivial tests. Define what correct behavior looks like, then iterate against it until the fix works.
Invest in creating a testable situation. I help a lot of people with really hard problems. I got to say that one of the hardest problems to solve is the so-called intermittent problem. Hey, sometimes it kind of does this, and that is hard to replicate, right? And that means that you can go make a change, but you don't really know what was wrong because you're not able to replicate the problem. Putting time into actually replicating a problem, putting your time into testing so that you can be, you know, figuring out what's wrong, really does pay dividends. This is different from like test-driven development, which is often about creating relatively trivial tests to describe you know, what the output of a given piece of code is going to be, and then designing the code until actually it passes that particular test. That can be useful, but it is not what I'm talking about here. What I'm talking about is when you're working on something hard, when you're trying to fix a complicated problem, start by asking, "What does true north look like?" Put yourself in a position where you can be taking that which you built and apply it and, like, find out whether or not it points true north. The faster you do that, the more you're gonna be able to create remarkable progress.
