Book summary: Pragmatic Thinking & Learning (III)

This is the third and last part of my summary of Pragmatic Thinking & Learning, by Andy Hunt. See parts one and two on this same blog. This part will cover chapters “Gain experience”, “Manage Focus” and “Beyond Expertise”.

Gain experience

Your brain is made to learn by exploring and building mental models on your own, not by receiving information passively (see amazing footage of tennis teacher in Alan Kay’s Doing with Images Makes Symbols, starting on 55:30). In real life there’s no curriculum, you’ll make mistakes and it will get messy: the kind of feedback you need. We learn by “playing”, but that doesn’t mean easy or non-business-like. Papert students called it “fun” because it was hard, not in spite of.

Leveraging existing knowledge helps learning new skills: we can often find similarities, literal or metaphorical, with existing skills. However, careful not to stick with the similarity. Fully embrace the new skill’s unique characteristics.

Failures are valuable because they can lead to study and understand what went wrong and how to fix it. They are critical to success, but only when well-managed. A good environment for good failures needs freedom to experiment (few problems have a single solution; prototype more than one solution to a problem), ability to backtrack to a stable state, reproduce any work product as of any time (source control, and the ability to run those versions of the program), ability to demonstrate progress (get comparable feedback between versions). Version control, unit testing and automation give this environment. A supporting environment can make or break learning for anyone.

Tip: to raise awareness when some code fails without apparent reason, try to imagine what the code should look like, then compare it to the real thing.

Time pressure actively shuts things down. Your vision narrows, and R-mode doesn’t get the chance to work at all.

Manage Focus

When not doing anything, the L-mode will produce incessant mental chatter, which interferes with R-mode processing. Meditation helps controlling the L-mode “monkey voice”.

When meditating you don’t want trance, falling asleep, or “contemplate the big mystery”, but to sink into a relaxed awareness of yourself and your environment without judgement or making responses. Meditation exercise suggestion: find a quiet spot; sit in a comfortable, alert position with a straight back (become aware of any tension and fix it); close you eyes and focus your awareness on your breath; be aware of the rhythm (don’t try to change it, just be aware); keep your mind focused on your breath (do not use words or start a conversation with yourself); when you start thinking about some topic or having a conversation with yourself, let the thoughts go and get the focus back on the breath. Even if you mind is wandering often, the exercise of bringing yourself back is useful.

You have to let your thoughts “marinate” to get the best results. Different people have different methods to marinate (sitting around doing nothing, humming, eating a crunchy snack, making paper dolls…). Thinking about at least three solutions to a problem gives you the confidence that you have thought “enough” about it. Then, you can let those ideas marinate and come up with the best solution.

Assorted tips:

  • Develop your exocortex (mental memory or processing outside your physical brain: book collection, notes, favourite IDE, etc).

  • Deliberate switching to e-mail/IM. Close what you’re working on, take a deep breath, then switch.

  • Have a way to note things quickly when they come up, without losing the flow or what you were doing (wiki/scratchpad inside you IDE or whatever).

  • When stuck or bored, doodle on a piece of paper, or go for a walk (without talking to anyone). That helps against checking the internet or e-mail.

  • Don’t answer IM right away, put up a sign (“don’t disturb”) during a debugging session or similar, or close the door if you have one. When you do get interrupted, try to save your mental state before you lose it.

  • Get two monitors (same size and brand) to keep the whole context at sight. Organise virtual desktops by task (communications/distractions, writing, coding/checking documentation, surfing), not by kind of application (browsers, editors, terminals).

In summary: learn to quiet your chattering L-mode, deliberately work with and add to thoughts in progress, and be aware of how expensive context switching can be.

Beyond Expertise

Change is harder than it looks, old habits don’t go away easily. Don’t be hard on yourself, just correct it and go back to the right path. Suggestions to make effective change:

  • Start with a plan. Keep track of what you have accomplished, it’s probably more than you think.

  • Inaction is the enemy, not error. The danger is not doing things wrong, is not doing anything.

  • New habits take time. Expect at least three weeks, maybe more.

  • Belief is real. If you think you’ll fail, you will.

  • Take small, next steps. Keep your big goal in mind, but don’t try to spell out all steps you need to get there.

Possible first steps (complete list on p. 247-248, this is just two highlights): (1) pick two things that’ll help you maintain context and avoid interruption, do them right away; (2) open your mind to aesthetics and additional sensory information (your cubicle, desktop, code: how “pleasing” is it?).

You don’t want to become a “niche expert”: approach learning without preconceived notions, prior judgement or a fixed viewpoint; be aware of your own reaction to new technology and ideas; be aware of yourself and the context. The biggest reason any of us fail is the autopilot.

And this is the end. I hope you liked it.