< expLog

On Thinking



  • No ideas but in things.


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


  • 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)


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.


  • 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 $ψ$\.
  • 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.