So what's wrong if you aren't an engineer?

Nothing at all! To quote Reg Brathwaite (again! But the man has a way of using words that is very eloquent. I can't resist).

[This is the second in a series of four blog entries. If you haven't already you might want to read part one first.]

What's wrong with being a clerk? Nothing. It's only a problem if deep in your heart you despise clerks and you spend your life in denial about the career you have chosen. I wouldn't wish that on anyone, so I asked my readers to think about that carefully.

Likewise, we can argue about what activities from programming can or cannot be considered Engineering. But really, even if you don't do any Engineering, what's wrong with that?

Heh!.

My last blog post seems to have ignited a mini firestorm. Observing how people react to an idea is sometimes more fun than the original idea itself. Reg gets it. In one of his replies to a comment (do read his blog entry), he says

"the statement “~p implies ~q” says nothing about whether p implies q." .(typo corrected. Thanks Arne!)

This is a bit more subtle than it seems. Try substituting p = "You use mathematics" and q = "You are an engineer") and try working out "~p => ~q" and " p => q" ( => is implication and ~ is not). You may be surprised !

I am continually astounded at how many people respond to arguments or claims without doing a logical analysis of what's being said. (Note: I am using "argument" and "claim" (and other words like "theory") in the logical/scientific sense, NOT in the " I had this 3 hours argument with my wife. She asked me to wash the car and I refused. At the end I was shouting and she was in tears. My theory is that women are a different species" sense).

When I was a debater, in my younger days, one of the lessons I learned early is to understand that you don't counter an argument from your emotional or "gut" level, by calling your opponent names, or attributing motives to him (unless you are trying to be a politician, when these tactics do pay off).The way to counter an argument is to dissect its logical structure, and show it is invalid (in specific contexts, if required). Rhetoric by itself can be powerful (and many politicians know this), but when layered on top of a logically sound argument is devastating. There are very precise ways of doing this, going back many centuries, at least as far as Aristotle and Plato.

In my last blog post, I made the claim that most software developers are not engineers. Here, I'll make another claim, even more provocative. Most software developers don't understand logic either. You think I am wrong? Quick, (assuming you are a software developer) what is the difference between the "if .. then" construct in programming languages like java and the logical "if ..then" (aka implication, often denoted by =>) ? If you, a software developer, answered correctly without having to think about it, rest assured, you are in a minority.

Using logical implication you can say(assuming we are talking about this Earth and this time stream) "If Napoleon Bonaparte was born in Europe, the Sun rises in the East" and have it evaluate to true. But of course. What's so surprising? "If Napoleon Bonaparte was born in India, the sun rises in the West" or "If Napoleon Bonaparte was born in India, the sun rises in the East" also evaluate to True! :-D. ("If Napoleon Bonaparte was born in Europe, the sun rises in the West" evaluates to False.) What does the birthplace of Napoleon Bonaparte have to do with where the sun rises? ;-)

Confused? heh! Don't worry it is a most people get totally zonked when they see this example for th first time. The key is to realize that implication is not causation. (neither is correlation but that is another topic. See this debunking of a claim that "research supports the effectiveness of TDD" to see an example of correlation vs causation - The trick I pulled is of course that many variants of the English "If.. then" are different from the logical "if ..then". [1]). Many people learn the truth table of implication without really internalizing what it means.

When I teach programmers first order logic, this is a constant stumbling block. The solution is simple. I ask them to think of the logical "if X then Y" (where x and Y are booleans or boolean valued expressions) construct as equivalent to a programmatic "If X then Y else True". The "else True " is key. In other words, (thinking programatically) does X have a value of true? if so return (the truth value of) Y else return true. Apply this to the "Napoleon" arguments and you'll get the correct (logical) answer for all possible combinations.

Why is such a confusing notion important? Proofs are logical structures using the primitives of FOL. A large part of mathematics(and science) is proofs. From science comes engineering. and if you are not using mathematics you are not an engineer (ducks for cover ;-)).

There are 5 connectives (not, and, or, if (or implication) and iff (or double implication) ) and two quantifications (Universal and existential) in First Order Logic, which need to be mastered before one can go on to things like proofs and logical structure. That's the bad news. The good news is that working through a book on logic (and there are PLENTY of those) will teach you how to use logic.

Reg goes on to say (in the same comment stream)

I remind everyone that "exists x such that x ~member of E does not imply that for all x, x ~member of E."

In other words, the fact that not using math means you aren't an Engineer does not imply that using math makes you an Engineer, for whatever definition of math we agree on.

Exactly so!

The point of the last blog post wasn't "you suck you enterprise developer subhuman moron", but "Don't delude yourself". No more, No less. Do what you love. And have fun!

PS: Once you know logic, using to to construct (or deconstruct) an argument is trivial. But for those who want to make sound arguments without necessarily studying "raw" logic (I hope you are not a sw dev ;-)), take a look at "The Craft of Argument" by Joseph Williams and Gregory Colomb.)

[1] Wikipedia

Part Three of this series is here.