Four rules. That's all you need.
They work for everything from tractors to software to cats to relationships.
What is it? Identifying something can be half the battle. If you'd known it was an ATI card instead of an nVidia, or a 1964 Chevrolet instead of a 1963, or a fuckbuddy relationship versus a potential marriage, that can make all the difference.
What's it supposed to do? If you don't know what something looks like when it works right, you have no chance of figuring out that it's even working wrong, let alone what to do about it.
When was the last time it did that? If the thing never worked right, it's different than if it worked for years right up until last night.
What'd you do to fuck it up? The nicer version of this is, "what changed?" Stuff doesn't work one day and then just doesn't work the next day without something changing. And often enough, it was something you or somebody else diddled with. Knowing what the change factor was is crucial.
My Four Debugging Rules04/08/2008 08:47 PM
- 