Is this something which one can learn and use in other walks of life, for example programming or ML?
Edit:
What I often find is that reading this type of material seems very mentally stimulating, but these texts do not seem to offer any introduction or intuition as to why someone should learn this material or how to use it outside of the logic domain.
You've got it backwards. Logic isn't a domain, just like algebra isn't a domain. Logic is what lets us work within a given domain. It isn't like geometry, which won't be useful unless you're working with shapes and angles; logics (and, more generally, algebras) are the syntax of entity relations.
In particular, logic is about "preserving truth between statements". That is, if we have a set of true statements, and we want to generate new true statements, logic is the way to do that, and it's always done in the same way, using arguments.
That word has two common meanings, but the arguments of logic are: premises, linked by deductive rules to conclusions. If the deductive rules are valid, and the premises are true, then the conclusions will deductively also be true. "Premises" can be any type of statement that has a truth-value (i.e. makes a claim about a fact).
So, obviously, this is the basis of all proofs, in any discipline. But it's also the foundation of rational persuasion, as in a court room. Which is to say that you're already using informal logic, every day. The question is "would it be useful in your life to learn these things formally?"
What's the difference between someone with the intuition "the opposite side of the 90° angle in a triangle is always the largest", versus someone who understands the Pythagorean theorem?
Philosophically, I prefer the reasonable / rational / meta-rational framework explained by David Chapman. [1] But if you want to know how people ordinarily think, better to study how they think.
(And in practical everyday use on the Internet, I find logic mostly useful for for shooting down attempts at inappropriately applying logic to conclude things that you can't safely conclude.)
"Well then, if you believe that then you'll believe anything."
Sounds pretty folksy to me.
It's generally very easy to find natural language constructs that rely on any given principle of formal logic. For the principle of explosion, an example would be "if you're thirsty, there's tea in the kitchen".
It's ultimately stuff that feels obvious-in-hindsight and thus easy to undervalue, but for me it encompasses matters such as:
1) Making sure that a desired solution actually addresses an explicitly understood problem (other than "the problem is that the desired solution isn't in place!") This means being able to explicitly state the problem and symptoms as a state of current reality, separate from discussion of what the solution should be.
2) Resisting the urge to seize on the easiest-to-grasp potential cause of an effect (this is a big one with many programmers, I am constantly asking things like, "are you sure that's the only possible cause?" and "but if that were the cause, wouldn't this other effect, which is not happening, also be happening?") People can waste a lot of time chasing theories that don't fully explain the symptoms.
3) Constantly testing and updating mental models. For instance, I am frequently urging team members to state their expectations before running an experiment, rather than just "seeing what happens". For example, "now that I have set this configuration value, I expect to see this effect". This is to guard against the "let's just hack until it seems to work" phenomenon, which is a recipe for introducing latent bugs from not understanding the whole system/model.
4) Better communication! Engineers have a habit of speaking in shorthand, causing other people to say, "Wait, can we back up a bit?" (Or worse, not doing so when they should.) Explicitly setting context up front, including explicitly stating assumptions up front, better sets the table for group discussions where everyone is on the same page. Under-communicating is more frustrating than over-communicating.
5) The final benefit of #4 is that if you are responsible about stating the premises/assumptions that lead to your conclusion, then you have effectively depersonalized the discussion. Such that, if through discussion you discover that a premise/assumption underlying a conclusion is incorrect, then you can easily switch gears. Since the conclusion flowed from that set of stated premises, rather than "Person X being adamant", then it is easier that Premise #3 is wrong than "Person X being wrong".
Anyway, all of these practices are easier to implement and follow if you have an appreciation for the kinds of logical concepts taught in basic logic courses.
https://www.amazon.com/Meaning-Argument-Introduction-Through...
It goes even further then this in the sense that with logic you can design a language with correctness checking where even the logic of your entire program can be verified via something similar to a type check. So for example, Agda or Idris are examples of languages with this capability.
So basically most of this stuff isn't relative to most job. It's a higher level thing. It's more advanced theory for the people who create the tools SO you can do your job. A step above Dev Ops... it's the people who create the languages you use.