#+TITLE: On Thinking
#+OPTIONS: H:6

* tl;drs
** General
- No ideas but in things.

** Mathematics
- Be precise with language, and in general.
- It's valuable to think about how I think: apply metacognition to improve.

** Systems
- Build processes and systems to be as simple as possible, allowing
for human behavior.
- Expect counter-intuitive and surprising behavior from complex,
overly rigid structures.
- Categories of business problems
- Who & What (things, people, and roles)
- How Much (measuring and counting)
- When (scheduling and timing)
- Where (direction and how things fit)
- How (how things influence each other)
- Why (seeing the big picture)

* Sources
** Mathematical Thinking
While I've been focusing on Writing as thinking, I realized that often
enough I don't have a way to validate my results. Writing my thought
process out helps catch inconsistencies, sloppy thinking, incomplete
ideas -- but it's still possible to simply be wrong.

I'm reading  -- and working through problems -- around thinking
mathematically to help navigate the rest of my life.

*** Introduction to Mathematical Thinking
I've started realizing that my mathematical fundamentals have become
weak; I suspect they might never have been as strong as I imagined in
the first place.

A simple example of an incorrect assumption I've had for a long time:
that $(p_1 * p_2 * p_3 *... * p_n) + 1$ is always a
prime. $2*3*5*7*11*13 + 1 = 30031$ is $59^2$.

Mathematics requires precision: which is what requires mathematical
notation, and paying attention to precision of language (and no head
injuries).

Notation in mathematics relies on stripped down versions of words used
in common language:
- and, or $\land$ is strictly used to combine the truth values of 2
statements, and doesn't hold any meaning around consequence or
ordering.
- or, or $\lor$ means an inclusive or, and not the exclusive
("either") or.
- not, or $\lnot$ is true negation; it cannot be used loosely.

- Implies includes both causal and truth-value conditional between the
antecedent and the consequent.
- The conditional is represented by $\implies$, which attaches no
direct meaning to the antecedent or consequent; they need not be
related.
file:../static/images/implies.png

- The truth table for implies is meaningful when there is a true
antecedent; it's somewhat meaningless for a false antecedent and is
defined by looking at the inverse.
- Equivalence is when $\phi$ implies $\psi$ and $\psi$ implies $\phi$;
it's also referred to as "iff", or "if and only if".
- $\forall$ and $\exists$ help define the context for statements, and
must be applied carefully in the correct order.

After explaining the combinators and quantifiers, the author moves on
to proofs. Proofs are essentially a collection of arguments that
validate a statement in incremental steps.

A proof servers 2 purposes
- Evaluating if a statement is correct
- Communicating the correctness of the statement to others

While it's a very bad idea to fit every problem to a template, there
are patterns that can be applied to construct proofs:
- Proof by Contradiction: To prove $\phi$, assume $\neg\phi$ and reach
a point that is obviously false. This proves $\neg\phi => F$, which
is the contrapositive to $T => \phi$; or $\phi$ is true.
- Proving Conditionals: To prove $\phi => \psi$, assume $\phi$ and
derive $\psi$\.
- Proving Quantified Statements: Solve these either directly or by
contrapositive, whichever proves to be simpler.
- Proof by induction: Assume $f(n)$, and derive $f(n + 1)$.

(I have to admit that I kept thinking of the similarities to programs
throughout this section: programs tell computers what to do, and
humans what they do; and applying patterns to programming makes the
process all the more simpler.)

*** How Not to be Wrong, the power of Mathematical Thinking
There are several fascinating anecdotes in this book around actually
reasoning about the world: starting with the famous example of adding
armor to aircraft where there aren't bullet holes.

I've always been skeptical of claiming to understand an algorithm
without actually implementing it; the same applies to every other
endeavor to learn -- and is beautifully captured by a quote I first
came across in this book: No ideas but in things.

*** How to Solve it
I read Polya's book on tackling problems when I was in high school,
and I've relied on the heuristics from the book ever since. The core
of the book is around 4 ideas:
- Understand the problem
- Create a plan
- Execute the plan
- Review the solution

The book then goes into various heuristics that help in approaching
problems; I also found it very valuable to think about
metacognition.

In retrospect, my note about debugging was probably
inspired by How to Solve it without consciously realizing it.

** Systems Thinking

*** The Back of the Napkin
I realized that simply sketching things out was extremely valuable to
be able to think things through. Feynman diagrams are one example of
notation that help with thinking.

Searching for thinking with drawing lead me to this book; it's a bit
more business-y than I'm used to, but seems interesting nevertheless.

*** Systemantics, aka The Systems Bible
Systemantics is one of the most fascinating books I've read.

I've referred to Small Gods by Terry Pratchett as one of my favorite
books of all time because of the core message of the book -- to pay
deep attention to the heart of everything and avoid getting distracted
by appearances. System-Antics reinforced this principle, and also
shows how appearances can become more important than the core function
of a system and take it over.

**** Interacting with Systems and the people within them

The biggest takeaway I had to was to be extremely wary of grandiose,
complex systems. If I'm in a position to build a new system, to make
it as simple and obvious as possible. If I'm forced to interact with
an existing system, tread with extreme care and the expectation that
it'll be barely functioning as described.

Some tactics to work with large systems include looking out for
reinforcing feedback loops, understanding what the inputs to the
system look like -- and what the reality of the system is. Accepting
that communicating with a system is necessarily inefficient and
unlikely to achieve any results. And always watching out for the
system to react badly to any changes.

Simple direct systems are best: ideally, they go with the flow and
don't oppose human tendencies. There must also be a lot of slack in
the system to give it space to stretch and allow for people to adjust
and make space for themselves.

As a manager, the best thing you can do is to remove obstacles.

Frames of reference are very important while considering and
interacting with systems. Being part of a system necessarily forces me
to be a part of the delusions of that system; and that explains a lot
of my life.

It's worth doing things poorly if it's worth doing them is a dramatic
change from my usual approach to life, but far more pragmatic. I have
perfectionist tendencies that mean I don't really get very far with my
projects, and often lose a lot of potential value because I can't do
something well enough.

**** Explaining the world, and parts of my life
Some of my greatest successes have happened in spite of the system
that was supposed to create them, and not because of it: particularly
at school, and sadly, also at work.

I've also spent several years of my life trying to build systems at
work, only to see them backfire or misbehave in different ways --
instead of trying to make smaller, targeted changes.

I must admit that this also explains the behaviors of engineers I've
seen be consistently successful in building value.

The explanations of constantly failing systems also helps explain the
state of the world today, and why specialized organizations don't seem
to be as successful as you would expect.

**** The book itself
The book itself is written in a satirical-scientific style with dry
humor throughout: looking at reviews online, it might also put you
off the book but I'd recommend powering through the first few chapters
and it'll become impossible to put down.