5 ms·

Not just your infrastructure, your code base too. I've seen a lot of developers practice what I call "debugging by superstition," where they make random changes

Not just your infrastructure, your code base too. I've seen a lot of developers practice what I call "debugging by superstition," where they make random changes until it appears to work. I prefer to keep digging until I understand. Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different. One benefit of experience is that you gain a better intuition about your hypotheses, and you know how to more quickly devise "experiments" to test them. Also if you know more things in depth (because of prior digging) you don't have so many rabbit holes to explore. Another benefit of waiting until you understand is that you don't make bull-in-a-china-closet edits to unfamiliar code. As a freelancer I have a strong bias towards adopting the style/patterns/architecture of whatever code base I'm working in. I wish more people did this! More often programmers skim through some code and start making changes, without trying to learn why the code is how it is or what other parts of the system need it that way. Since this is the Internet I feel compelled to add: of course moderation in all things.

deleted 12y ago
[deleted]
quanticle 12y ago
>Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different. As Adam Savage [1] says, "The only difference between science and screwing around is writing it down." I don't follow this process for every problem I encounter, but when I have a really intractable issue, where nothing I've thought of seems to work, I start a "lab notebook" (usually a few sheets of printer paper). I write down all my assumptions, and start designing experiments to test each one in turn. It's a fair amount of overhead (which is why I don't use this approach for everything), but when all else fails, the scientific method powers through. [1] https://www.youtube.com/watch?v=BSUMBBFjxrY https://www.youtube.com/watch?v=BSUMBBFjxrY
- vacri 12y ago
  As Adam Savage [1] says, "The only difference between science and screwing around is writing it down." Not true at all, though publishing is an important step. Understanding what is going on is important. A startling revelation that the MythBusters guys have no understanding of statistics was when they invented their buttery-toast dropper. Doing a 'calibration' dry run (literal dry run!) with toast with one side marked with an X instead of butter, 7 out of 10 trials read one way. Adam remarked "This isn't random enough - it should be 5!". The Mythbuster guys get 11/10 for curiosity and the spirit of investigation, but 4/10 for scientific rigour :)
  - quanticle 12y ago
    That's not how I interpreted it at all. To me "writing it down" has nothing to do with publishing. "Writing it down" means that you systematically track the results of your experiments and then you use those results to update your hypotheses. If you don't write anything down, you're debugging by superstition.
    - vacri 12y ago
      I would not categorise that rather complex set of activities as 'only'. It's not just 'writing down', but analysing, predicting, and designing new experiments.
  - dredmorbius 12y ago
    I'd have to see the segment in question, but that sounds suspiciously like an ironic comment.
MichaelGG 12y ago
Yes I get very annoyed when I see some strange looking code written because the right way "didn't work" or "there was a problem". Sometimes that's a legitimate reason, with legacy/buggy/messy systems, when you just don't have the time or effort to do it right. But then at least document the hack as what it is. And what the general issue with the obvious approach was.
protomyth 12y ago
I saw this in a code base once: Line above commented out seems to fix Bug 34541 This makes for an impressive code land mine and creates some seriously unhealthy superstitions.

deleted 12y ago

[deleted]

quanticle 12y ago

>Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different. As Adam Savage [1] says, "The only difference between science and screwing around is writing it down." I don't follow this process for every problem I encounter, but when I have a really intractable issue, where nothing I've thought of seems to work, I start a "lab notebook" (usually a few sheets of printer paper). I write down all my assumptions, and start designing experiments to test each one in turn. It's a fair amount of overhead (which is why I don't use this approach for everything), but when all else fails, the scientific method powers through. [1] https://www.youtube.com/watch?v=BSUMBBFjxrY https://www.youtube.com/watch?v=BSUMBBFjxrY

vacri 12y ago
As Adam Savage [1] says, "The only difference between science and screwing around is writing it down." Not true at all, though publishing is an important step. Understanding what is going on is important. A startling revelation that the MythBusters guys have no understanding of statistics was when they invented their buttery-toast dropper. Doing a 'calibration' dry run (literal dry run!) with toast with one side marked with an X instead of butter, 7 out of 10 trials read one way. Adam remarked "This isn't random enough - it should be 5!". The Mythbuster guys get 11/10 for curiosity and the spirit of investigation, but 4/10 for scientific rigour :)
- quanticle 12y ago
  That's not how I interpreted it at all. To me "writing it down" has nothing to do with publishing. "Writing it down" means that you systematically track the results of your experiments and then you use those results to update your hypotheses. If you don't write anything down, you're debugging by superstition.
  - vacri 12y ago
    I would not categorise that rather complex set of activities as 'only'. It's not just 'writing down', but analysing, predicting, and designing new experiments.
- dredmorbius 12y ago
  I'd have to see the segment in question, but that sounds suspiciously like an ironic comment.

MichaelGG 12y ago

Yes I get very annoyed when I see some strange looking code written because the right way "didn't work" or "there was a problem". Sometimes that's a legitimate reason, with legacy/buggy/messy systems, when you just don't have the time or effort to do it right. But then at least document the hack as what it is. And what the general issue with the obvious approach was.

protomyth 12y ago

I saw this in a code base once: Line above commented out seems to fix Bug 34541 This makes for an impressive code land mine and creates some seriously unhealthy superstitions.