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.

Get in Your Right Mind

A good way to involve your brain more is to use more senses than usual. For tactile you can use building blocks like Lego, CRC cards, etc. Example of “role-playing” a software design on p. 77. The advantage of using the R-mode is not that it’s a panacea, it’s simply to use the other half of your brain too (reference to pair programming). Story of the climbing teacher on p. 81: the importance of feeling something first (R-mode) before learning it’s theory (L-mode), because it gives you the context to understand the theory and explanations better. Learning can be impeded by trying to memorise facts when you don’t grasp the whole yet. When creating, be comfortable with the absurd and impractical; when learning, get “used to it” before learning and memorising. Using metaphors can open up creativity because they communicate the R-mode and the L-mode (wordnet can help when creating metaphors).

Tip: the “morning pages” technique (p. 98). Write them first thing in the morning (before coffee, shower or anything else); write at least three pages by hand, without computer; do not censor what you write; do not skip a day. Blogging is also a good exercise (what you think about a topic, what you can defend publicly).

Tip: learn martial arts or yoga to improve concentration (p. 103). Tip: break small, daily routines (turn off the autopilot).

Forcing the brain to reconcile unlike patterns broadens the scope of material under consideration (see Zen koans and Greek oracles on p. 107). Reference to oblique strategies (has electronic versions, including an Android version!).

Debug Your Mind

We make decisions and solve problems based on faulty memory and our emotional state of the time, ignoring crucial facts, etc. Some cognitive biases: anchoring (ref: experiment with numbers and prices in predictably irrational), fundamental attribution error (other people behave based on their personality, we have excuses for our own behaviour; in reality, behaviour is often caused by the context), self-serving bias (“it’s my success”, but “it’s not my failure”; you’re always part of the system), need for closure (naturally uncomfortable with uncertainty; have to learn to live with it), confirmation bias, exposure effect (prefer familiar things), Hawthorne effect (people change when they’re being watched, but after a while they go back to how they were behaving), false memory (easy to confuse imagined events with real memories; every memory read is a write in light of the current context), symbolic reduction fallacy (L-mode is anxious to “symbol-away” complexity), nominal fallacy (thinking that labelling a thing means you understand it).

How to fight biases: understand that “rarely” doesn’t mean “never”, defer closure (you know the most about a project at the end of it, so don’t take decisions too early, be comfortable with uncertainty), remember that you don’t remember well. People are mainly a product of their environment and of the times. Explanation of different American generations on p. 125-131. In summary, generational archetypes are prophet (vision, values), nomad (liberty, survival, honor), hero (community, affluence) and artist (pluralism, expertise, due process). Realise where your thinking is coming from, what are your influences, and what kind of arguments you make. Try to have a diverse team so biases can catch/cancel each other. Myers Briggs Type Indicator discussion on p. 133-135. Trust intuition, but verify. If you think you have defined something, try to define the opposite.

Learn Deliberately

A single intense, out-of-context classroom event can only get you started in the right direction. You need continued goals, feedback to understand your progress and approach it far more deliberately than a once-a-year course.

For any goal (desired state, usually short-term) you have in mind you need a plan, a series of objectives (steps towards that goal). Objectives should be Specific (“learn Erlang” vs. “be able to write a web server in Erlang that dynamically generates content”), Measurable (how do you know when you’re done? related to “specific”. You don’t have to see where you’re going, just a couple of meters ahead of you), Achievable (from the current state!), Relevant (does it matter to you? is it under your control?) and Time-boxed (perhaps the most important: the deadline).

Create Pragmatic Investment Plans (PIP) to learn whatever you want to learn. Major point involving managing the plan:

• Have a concrete plan: devise different levels of goals (now, next year, next five years).
• Diversify: make an effort to choose different methodologies, languages, industries, and non-technical stuff.
• Active investment: need to be able to evaluate your plan and realistically judge how’s going. Adapt/change the plan based on that.
• Invest regularly: you need to make a commitment to invest a minimum of time on a regular basis. Create a ritual, if needed.

Other techniques, like mind maps, talk to the duck and learning by teaching are mentioned in this chapter, but I’m skipping them in the summary.

And this is the end of the second part of my summary. The next one will cover the rest of the book, namely chapters “Gain experience”, “Manage Focus” and “Beyond Expertise”.

EDIT: read the third part of this summary.

Introduction

Despite advances in programming languages, techniques, methodologies, …, the defect density has remained fairly constant. Maybe we’re focusing on the wrong things: software is created in your head.

You don’t get taught, you have to learn. Everything is connected, there’s nothing in isolation, so sometimes small things can have unexpectedly larger effects.

Journey from Novice to Expert

The novice needs clear, context-free rules to operate, but an expert is ineffective when constrained by those same rules. Experts don’t just “know more” than novices, they experience fundamental differences in how they perceive the world, approach problem solving, etc. The stages of learning in the Dreyfus model are:

• Novices. Have little or no previous experience in this skill area (“experience” results in a change of thinking; doing the same for years doesn’t count!). They don’t particularly want to learn, want to accomplish an immediate goal, don’t know how to respond to mistakes and are fairly vulnerable to confusion when things go awry (example of doing taxes for years on p. 20).
• Advanced Beginners. Can start to break from the fixed rule set a little bit. Can try tasks on their own but have trouble troubleshooting. They want information fast (eg. API reference) and can start using advice in the correct context, but don’t have a holistic understanding and really don’t want it yet.
• Competent. Can develop mental models and work with them effectively, troubleshoot problems on their own, and begin to figure out how to solve novel problems, as well as seek and take advice from experts. They’re typically described as “having initiative” or “resourceful” and tend to be in a leadership role in the team (formal or not). They’re great to have on your team because they can mentor the novices while not annoying the experts.
• Proficient. Need the big picture, and thus will seek out and try to understand the larger conceptual framework around the skill. They’re frustrated by simplified information. This is the first level that can correct previous poor performance and revise their approach. They can also learn from the experience of others, which comes with the ability to understand and apply maxims.
• Experts. Primary sources of knowledge and information in any field, continually looking for better methods and better ways of doing things. Statistically, there aren’t many: probably around 1-5%. Experts work on intuition, not reason. They may be completely inarticulate as to how they arrived at a conclusion. They aren’t perfect though, and have the same cognitive biases as everyone else. They’re also likely to disagree with one another.

Most people, for most skills, never get past the second stage. Plus, practitioners at a lower skill level have a marked tendency to overestimate their own abilities. Note that you want a mix of skills on a team. See “10 years to expertise” on p. 32. The dangers of overreliance on formal models (I’m skipping some in this list!):

• Confusing the model with reality. It’s easy to confuse the two, but they aren’t the same.
• Devaluing traits that cannot be formalised. Good problem-solving skills are critical to our jobs, but problem solving is a very hard thing to formalise.
• Legislating behaviour that contradicts individual autonomy. You want thinking, responsible developers. Don’t reward herd behaviour.
• Alienating experienced practitioners in favour of novices. Targeting your methodology to novices, you create a poor working environment for the more experienced.
• Oversimplification of complex situations. Every project/situation is more complex than that.
• Demand for excessive conformity. What worked great in your last project might be a disaster in the next one.
• Insensitivity to contextual nuances. Formal methods are geared to the typical, not the particular. But when does the “typical” ever happen?
• Mystification. Speech becomes so sloganised that it becomes trivial and loses meaning (eg. “we’re a customer-focused organisation”).

This is your brain

You have two “CPUs”: the linear, logical thought and language processing CPU (“L-mode”, for “linear”; the “left part of the brain”); and the searching and pattern matching CPU (The “R-mode”, for “rich”; the “right part of the brain”). They share the same bus so they can’t function at the same time.

R-mode can search “asynchronously” and come up with the response (possibly days) later. It doesn’t do any verbal processing, so the results are not verbal either (eg. trying to describe dreams). Also, it’s not under our direct concious control: as it can give answers anytime, we have to be ready to write down anything that comes up (related: everyone has good ideas, but far fewer track them; of those, even fewer bother to act on those ideas, and even fewer of those have the resources to make a good idea a success). It is very concrete, relating things as they are; it makes analogies and doesn’t require reason or known facts to process input. It’s holistic and wants to see the whole thing at once, perceiving overall patterns and structures. It’s intuitive, making leaps of insight, based on incomplete patterns, hunches, feelings or visual images. It’s very useful for software design.

Synthesis can be good for learning, see “Don’t Dissect the Frog, Build It” on p. 62. Aesthetics also make a difference, see p. 66-67. The brain is wonderfully plastic. There’s no limit to the number of skills you can learn, as long as you believe it (ie. what you think about your brain capabilities physically affects the “wiring” of the brain itself).

And that’s all for now. The next part will cover chapters ”Get in Your Right Mind” and “Debug Your Mind”.

EDIT: read the second part of this summary.

But. I. don’t. test. my. programs.

By hand, that is. And sometimes (usually) the coverage is not enough, and I end up making embarrassing mistakes. It usually happens outside of work, although at work I also have my share. The last one was with the Debian package dhelp, where trying to fix an issue before Lenny is released, I ended up making it even worse. The story goes like this:

There was some problem with the indexing of documents on installation/upgrade (namely, it would take ages for most people upgrading to Lenny, and they would think the upgrade process had hung). So, I go and change the indexing code so it ignores documents on installation/upgrade. Also, as suggested by someone, I created some small example utility to reindex documentation for certain packages. I test installation, upgrades, upgrade of the dhelp package itself, the utility, searching for keywords before and after all that… and everything worked.

Only that I made a typo. A typo that would make all indexing to be ignored (except for the example utility, because it was a bit lower level). And I didn’t realise, because it “only” broke some cronjob, a completely different part of the package. And it happens that the cronjob reindexed everything weekly, to make sure that you had reasonably up-to-date search indices. And it also happens that, given that the documentation reindexing was being ignored on package installation/upgrade, the weekly total reindex process was the only thing that could provide the user with indexed documentation. But I screwed up. Oh well.

Someone filed a bug yesterday, and I fixed more or less right away. But this time I spent a couple of hours thinking of test paths and ways to make it fail, and actually doing all that testing. Thanks to that, I found some potential bug in the example utility, that I fixed just in case. So hopefully everything is fine now, if I can convince the Release Masters to allow the new, less broken update to dhelp to be accepted for Lenny.

I think I need personal QA. Anyone up to the task?