Comment by heikkilevanto

Comment by heikkilevanto 6 days ago

Some additional rules: - "It is your own fault". Always suspect your code changes before anything else. It can be a compiler bug or even a hardware error, but those are very rare. - "When you find a bug, go back hunt down its family and friends". Think where else the same kind of thing could have happened, and check those. - "Optimize for the user first, the maintenance programmer second, and last if at all for the computer".

physicles 6 days ago

The first one is known in the Pragmatic Programmer as “select isn’t broken.” Summarized at https://blog.codinghorror.com/the-first-rule-of-programming-...

Reply View 0 replies

bsammon 6 days ago

Alternatively, I've found the "Maybe it's a bug. I'll try an make a test case I can report on the mailing list" approach useful at times.

Usually, in the process of reducing my error-generating code down to a simpler case, I find the bug in my logic. I've been fortunate that heisenbugs have been rare.

Once or twice, I have ended up with something to report to the devs. Generally, those were libraries (probably from sourceforge/github) with only a few hundred or less users that did not get a lot of testing.

Reply View 0 replies

wormlord 6 days ago

I always have the mindset of "its my fault". My Linux workstation constantly crashing because of the i9-13900k in it was honestly humiliating. Was very relieved when I realized it was the CPU and not some impossible to find code error.

Reply View 1 reply

dehrmann 6 days ago

Linux is like an abusive relationship in that way--it's always your fault.

Reply View | 0 replies

ajuc 6 days ago

It's healthier to assume your code is wrong than otherwise. But it's best to simply bisect the cause-effect chain a few more times and be sure.

Reply View 0 replies

astrobe_ 6 days ago

About "family and friends", a couple of times by fixing minor and a priori unrelated side issues, it revealed the bug I was after.

Reply View 0 replies