[Gimpei]

I struggle with Feyerabend a bit. First, a big part of that book is case studies and the problem with case studies is that they are not representative of the underlying population. It’s very easy to simply cherry pick examples that advance your thesis, whereas what we really care about is population averages.

Second, let’s assume there is no method for arriving at truth. Well then how do we verify that some discovery is actually a discovery? Presumably if there was a way to do this, we could incorporate it into our method, thus undermining Feyerabend’s thesis. Well it turns out that his answer to this is to say that evaluation should consist entirely in the contribution of the discovery to happiness and flourishing. This could be useful at a general level, but seems useless when it comes to judging between theories and research paths within science.

[kijin]

Feyerabend may or may not have been right about physics or astronomy, but he sure as hell sounds like he knew what software engineering would be like.

Should programs be written in a procedural, object-oriented, or functional style? Just how much should you care about scalability when you're building your MVP? What's the best way to write tests for a program that makes API calls to servers you don't control? Rails or Next.js? Emacs or vi?

There's no tried and true method for determining the answer to any of the above. Most people will say "it depends." Depends on what? How do you tell if you made the right choice? Very often, you can only tell afterward when your company gets a bazillion users and your servers start crashing left and right. Even then, the answer is fairly subjective and boils down to whether your team, shareholders, and users are happy.