Review: Logical and Critical Thinking - Future Learn

Logical and Critical Thinking

Looking  for a bit of clarity

I have (in my own mind)  been struggling with both giving my own arguments and interpreting arguments of others - mainly in the workplace - but also elsewhere. 

I undertook this free course: Logical and Critical thinking created  - in part- by the University of Auckland.

My interest was piqued because I am certain that good logical and critical thinking can help drive out  more clear solutions and help with more clear testing and coding and generally participate in debates better (in relation to work) and that maybe it could help in other day to day aspects of reasoning.  

I have since read that it appears software engineering can actually foster better logical and critical thinking due to the need to tackle problems of different types and I can see that testing - in effect asserting truths and non-truths when validating behaviour - can also help, however I still think that a formal understanding could help hone these skills further. 

Over 8 "weeks" it takes you over the component parts of an argument, the main types and how to formulate, deconstruct and analyse arguments.

I'm under no illusion that this is Philosophy for dummies but I found it really thought provoking and far more engaging than I had anticipated.


Great examples

The 2 course leaders provide a blow by blow account of some of the following:
  • Statements
  • Fallacious arguments and common fallacies - including a worksheet on the 3 most common, this was an eye opener (more on this in a minute
  • Principle of charity
  • Standard Form (Premises and Conclusions)
  • Non-Deductive and Deductive arguments
  • Counter examples
  • Determining logically sound and cogent arguments
  • Scientific Method
  • Moral arguments
  • Case study to apply all of the learning from above 

It would be pointless to repeat or plagiarise everything I learnt - I've included a few standout takeaways below -  but what I can say is that, if anything, after the course and based on the principles learnt above, I think I can articulate my arguments - to help make people believe what I am saying - more effectively.  Likewise I am tuning into the validity of peoples' arguments better and this will help me discount or take on board what I am being asked to believe/buy into more effectively. I think the latter is extremely useful when looking for reasons to  - or not to do - take a particular approach(es) when weighing up technical solutions (not mutually exclusively to other empirical aids but in addition to)  

A few examples of applicability to a developers toolkit and software engineering and the engineering process

Some of the things I learnt I started applying immediately, I started to see logical fallacies rear their head and came to realise I have been arguing terribly for many years but also listening to terrible arguments from others! We are all at it (well from a logically valid argument point of view anyway) 

Standard Form

During one of the "weeks" on the course me and my team encountered a number of issues in work with one of our components., I was only in for part of the bug hunt due to illness but I was keen to apply what I had learnt, before I had to take time off (thankyou Covid-19).
 
I found it really effective to try and state the problems we were experiencing in standard form.  Writing arguments in this way, allows you to really quickly invalidate a conclusion, as if one of the premises is invalid it can not logically support the conclusion and the argument is not sound.

Affirming the consequent fallacy

One thing to look out for when problem finding, and a logical fallacy, is affirming the consequent. It's a bit of shortcut we often take (like framing and cognitive bias). An example would be if you once said, correctly,   "the endpoint is switched off,  therefore it is not processing any messages"  and later -  upon seeing a problem with the endpoint  incorrectly saying  "the endpoint is not processing any messages therefore the endpoint is switched off", here the inference is that there is only 1 reason the endpoint is not processing any messages, but - of course - there can be many reasons; it could be on, but it's not being sent any messages or, perhaps, all the messages it is receiving are failing due to an error.  I fall into this trap on occasion, especially on late night support calls, this would likely lead me to mentally closing off lines of enquiry mentally. 
This kind of logical issue is covered in the fallacious arguments section earlier on  in the course.

Ad-hominem (at the person) fallacy

Often, and I count myself guilty of this at times.  A person's character is brought into play when discussing  or evaluating their arguments.  For whatever reason, a bad encounter, difficult character traits or some other reason comes to bear and something about them is used to attempt to weaken their argument.   Obviously this is not truth seeking and it is something to be wary of.  Seeing this logical fallacy called out has made me acutely aware of it and want to attempt to not to allow this to cloud my reasoning. 

Summary

If not this course in particular I think that this is an area - certainly as a developer/engineer - worth exploring. It may help you get your point across or tune in more carefully to help assess good and bad arguments.  The course leaders suggested that logical and critical thinking needs to be practiced to be maintained though.  

Coupled with this course I have started to read the The Thinker's Toolkit - 14 powerful problem solving techniques I will review this in another post  Its related to the above, but I specifically wanted to understand some useful techniques when attempting to hone in on issues. 





Comments

Popular posts from this blog

Book Review: Test Driven Development By Example (Kent Beck)

SSDT March 2014 Static Code Analysis Extensibility

Testing, Testing, 1.2.3.4.5.6..ad infinitum