Method and Antimethod
2021-03-14 20:54:00 » blog, engineering, method
Paul Feyerabend’s Against Method is certainly a thinker in these modern times. There are already many great praises of it so I won’t add much to it, but I do want to be distinct about something.
Feyerabend, in AM, is Antimethod. He believes that method does not yield fruit. I think this is slightly disingenuous (he even concedes this is for rhetorical reasons in Science in a Free Society). There’s certainly a place for method alongside antimethod. The two are friends not enemies.
Method refers to a systematic process, or at least, continuing to think within the confines of some presuppositions or prevailing opinions. Method is deductive (though it may also incorporate empiricism).
Antimethod is ‘jumping out’ of the set of presuppositions. Breaking a subroutine. Throwing an exception. The prevailing metaphor of our times is ‘taking the red pill’ to jump out of the existing system. Putting on a new set of eyes.
Method is going down the rabbit hole. Antimethod is coming back up.
The thing, of course, is that we don’t want to jump out of a system and stay out. We want to jump over. Neo goes back into the Matrix with fresh eyes. Exceptions get handled. To throw your hands up and reject this call to go back into reality is the heresy of the Gnostics.
Antimethod isn’t something you can base your worldview and life on. It is something you use to break free of an oppressive strain of thinking, so you can then resume using method with a different set of presuppositions.
In engineer-speak, we call this part of the engineering process. We build things, then we test them and break them. Oftentimes, we find data that does not fit into our narrative we had going in. We have to use antimethod to brainstorm possible explanations for these processes before we can resume using method.
I’d personally best call this a heuristic interrupt. The goal of good thinking is to tune your rules of thumb and BS-detectors (your heuristics) so that they trigger you to jump out and into a different mode of thinking- a different bit of code- an interrupt handler. Not every problem can be tackled with the same mindset. Mindset shifts are required.
Scientific thinking has been hindered by such a refusal to break out of monotone and to harmonize. The engineers of the world, of course, are not impeded by such monotony. We have ‘blower-uppers’ like myself working hand-in-hand with clipboard-warrior rule followers. One group always doesn’t like the other. This push-pull dynamic isn’t a debate. It’s an argument. It’s not about facts in a presupposed environment.
Usually disagreeing engineering parties are fully informed. They know all the facts. Often, they aren’t even that stupid. They just have different value scales. As such, good engineering usually isn’t weighing facts- it’s applying heuristics about what is important.
Use your gut on how to use your brain.