It all started with a couple of conversations I have had with different people, about different topics. The common denominator was me not doing/buying certain stuff for “non-consumer reasons”. Some examples (feel free to skip):

• Apple. I don’t buy anything from Apple. The most important reason is that I don’t believe in a closed software ecosystem controlled by a single company (even if I know it has advantages in the short term). There are other reasons, like them trying to fight the right to jailbreak or them supporting SOPA.
• Sony/PlayStation. Although I do own a PlayStation 2, many things that have happened since then made me decide not to buy a PlayStation 3 (yes, there are many PS3 games, some of them exclusive, that make me drool and I’d love to play them). Partly closed systems, partly Sony fighting users’ rights on court and chasing homebrew developers, partly the draconian terms of the PSN.
• Being vegetarian/vegan. I’m actually not a vegetarian (but I’m somewhat close; long story), but I understand and support vegetarianism and veganism. I was pretty surprised that one concrete person I talked to about this hadn’t even thought of it as a form of belief or activism (the person thought vegetarians were, more or less, people who “don’t like meat”).

Note that I don’t claim to be right about these beliefs or about the best/most practical way to support them, but that’s completely besides the point I’m trying to make, namely that many people seem pretty surprised by those decisions, as if anything that doesn’t maximise your short-term “joy” or minimise the money spent was irrelevant when spending money. As if it was unthinkable not to be a Homo economicus. I mean, money has essentially zero influence on your happiness once you have enough to live comfortably. Thus, I fail to see how money should be a deciding factor for close to nothing at all (again, assuming you already have enough to live without worrying about money).

I think of myself, first and foremost, as a human being (with values, morals, empathy, etc), not as a consumer or a money-spender. For me it follows that mainly caring about money and “consumer values” is wrong, because that consumer identity I have can never override most of my other identities. Even feeling the need to write about this and explain it is pretty awkward. It seems to be a suspicious position to be in, as if you had to explain that not making “consumer values” the centre of your life doesn’t make you a crazy extremist. Part of this awkwardness is somewhat confirmed by a comment I have heard several times, something along the lines of “it’s your loss”, as if eg. having a PlayStation (as opposed to other consoles, or devoting your time to reading more books or jogging or playing board games or whatever) had to be more important than anything else I might care about.

But this is not just a philosophical question, there are two practical points in all this. The first is that how and where you spend your money matters and lot. Let’s say there’s two companies providing the same product. Company A offers it cheaper and uses illegal, poorly paid workers, while company B is more expensive but its workers have normal working conditions (this is of course a simplification for the sake of the argument). When you give your money to company A, you are saying that using illegal workforce with a shitty pay is ok as long as they give you a better price. You are saying than you, deep inside, care more about saving a couple of bucks than about having normal working conditions. Those decisions, our decisions, are what make companies behave in this or that way.

The second practical point is that if one makes all decisions based only on “consumer values”, you are defining your path of least resistance. And it’s big companies and lobby groups that have all the money and resources to make that path of least resistance something that makes you do whatever is in their interest (and possibly against yours, in the long term). And I know it’s human nature to save energy, be lazy, not think too much about every single thing we do, etc. I do that myself all the time. What kills me is not that people don’t resist, is that people don’t seem to see it as a limitation in themselves, but as a weirdness in anyone that tries to.

Introduction

How valuable are UI design guidelines depends on who applies them. They often describe goals, not actions, so they can’t be followed like a recipe. They also often conflict with each other. This book tries to give rationale to make them easier to apply.

Visual content

• Structure: Gestalt principles (proximity, similarity, continuity, closure, symmetry, figure/ground, common fate), see on p. 11-22. They act together, and sometimes they produce effects we don’t want: review designs with each of these principles in mind to see if they suggest a relationship that shouldn’t be there.
• Text: we’re wired for language, but not for reading. Typical text-related mistakes: geek-speak, tiny fonts (if the text is hard to read, it probably won’t be read, so you might as well remove it), burying important information in repetition, and using just too much text (use just enough to help most users get to their intended goals).
• Colour: our vision is optimised to detect contrasts (edges), and our ability to distinguish colours depends on how they are presented (colours are harder to distinguish if they’re pale, in small/thin patches or separated from each other). Guidelines for colour: (1) distinguish by saturation/brightness, not only hue, (2) use distinctive colours (red, green, yellow, blue, black and white), (3) avoid colour pairs that colour-blinds can’t distinguish (tips on p.59-60, including http://www.vischeck.com/), (4) don’t rely on colour alone, and (5) don’t place strong opponent colours next to each other (see p. 62).
• Peripheral vision: we only have good resolution in the centre of wherever we’re looking. Peripheral vision (1-2 centimetres from peripheral vision) mostly only provides cues for our eye movement (good example of bad error message, based on this, on p. 71). To make an error message visible: (1) put it where users are looking, (2) mark it (often it’s enough placing it next to what it refers to), (3) use an error symbol/icon, and (4) reserve red for errors. Heavy artillery (use with care!): (1) pop-ups, (2) sound (makes users scan the screen for errors; make sure they can hear it!), (3) motion or blinking (but not for more than a quarter- or half-second).
• Visual hints: use pictures where possible to convey function (quicker to recognise; memorable icons hint at their meaning, are distinguishable from others and consistently mean the same even across applications); thumbnails depict full-sized images effectively if they keep features; use visual cues to let users recognise where they are (distinctive visual style, colours, etc).

Expectations

Our perception is biased by our experience, current context and goals. Implications: (1) test your design to make sure different users interpret it in the same way; (2) be consistent with position, colours and font for elements that serve the same function; and (3) understand your users’ goals (they can be different, too!) and make sure you support them by making relevant information clearly visible at every stage.

Memory

We’re much better at recognising than at remembering (“see and choose” is easier than “recall and type”). Tips: (1) avoid modes, or if you can’t, show the current mode clearly; (2) show search terms when showing search results (they’re easy to forget if we get interrupted for whatever reason); (3) when showing instructions for a multi-step process, make sure the instructions are there while following the steps.

Attention and goals

When people focus their attention on their tools, it is pulled away from the details of the task. Software applications should not call attention to themselves. Short-term memory and attention are very limited, so don’t rely on them. Instead indicate what users have done versus what they have not yet done, and/or allow users to mark or move objects to indicate which ones they have worked on versus the rest.

Support people’s goal-execute-evaluate cycle: provide clear paths, including initial steps, for the goal; software concepts should be focused on the task rather than implementation, for the execution; provide feedback and status information to show users their progress towards their goal, and allow users to back out of tasks that didn’t take them toward their goal, for evaluation.

While pursuing a goal, people only notice things that seem related to it, and take familiar paths whenever possible rather than exploring new ones, esp. when working under deadlines. After they’re done, they often forget cleanup steps: design software so that users don’t need to remember, or at least to remind them.

Misc. tips:

• Don’t expect users to deduce information, tell them explicitly what they need to know.
• Don’t make users diagnose system problems. They don’t have the skills.
• Minimise the number and complexity of settings. People are really bad at optimising combinations of settings.
• Let people use perception rather than calculation, when possible (some problems, when presented graphically, allow people to achieve their goals with quick perceptual estimates instead of calculations).
• Make the system familiar (concepts, terminology, graphics), by following industry standards, by making the software work like an older application the user know, or by basing the design on metaphors.
• Let the computer do the math, don’t make people calculate things the computer can calculate for them.

Learning

We learn faster when operation and vocabulary is task-focused, and when risk is low:

• Task-focused operation: you have to understand the users’ goals in order to reduce the gap between what the user wants and the operations supported by the tool is called “the gulf of execution”. To understand goals: perform a task analysis (checklist on p. 135) and design a task-focused conceptual model (the list of objects/actions analysis the user should know about).  The second should be as simple as possible (ie. less concepts), avoid overlapping concepts, and not have things “just in case”. Only then sketch and design a user interface, based strictly on the task analysis.
• Task-focused vocabulary: it should be familiar and consistent (“same name, same thing; different name, different thing”), mapped 1:1 to the concepts.
• Low risk: often people are afraid of being “burned” and don’t learn or explore. People make mistakes, so systems should try to prevent errors where possible, make errors easy to detect by showing users what they have done, and allow users to undo/reverse easily.

Responsive systems

Responsiveness is not the same as performance, it can’t be fixed by having faster machines/software. Principles:

• Let you know immediately your input was received
• Provide some indication of how long operations will take
• Free you to do other things while waiting
• Manage queued events intelligently
• Perform housekeeping and low-priority tasks in the background
• Anticipate your most common requests

When showing progress indicators (always an operation takes longer than a few seconds): show work remaining; total progress, not progress on the current step; start percentages at 1%, not 0% (and display 100% only briefly at the end); show smooth, linear progress, not erratic bursts; use human-scale precision, not computer precision (“about 4 minutes” better than “240 seconds”).

Display important information first. Don’t wait to have all the information to show everything at once.

Summary

There has never been a “natural” body: bodies have always been the expression of a specific period, geography, sexual, religious and cultural place. However, today only a few aspirational and idealised body types are taking the place of all possible bodies. We’re losing body variety as fast as we’re losing languages. Again like with languages, there’s a critical period for “body acquisition”. We can feel alienated of our own body (for the rest of our lives) if we don’t learn to feel comfortable with it in that critical period.

The individual is now deemed accountable for his/her body and judged by it, turning “looking after oneself” into a moral value. A search for contentment around the body is a hallmark of our times, and a belief in both the perfectible body and the notion that we should accede to improve it has contributed to a progressively unstable body.

The body is becoming akin to a worthy personal object. Body transformation is today less of a social ritual, and more wanting to produce an acceptable body (wounded soldiers vs. TV contestants on p. 84-85). We seem to believe that almost anything about the body can be changed by the individual, turning plastic surgery into a consumer item: a treat, like a holiday. Sexuality has to be conjured and performed, it doesn’t exist or flow naturally.

The new grammar of visual culture, which is not even real (Photoshop), produces that even children photos are “enhanced”, generating frustration and even making people lose accurate records of their visual history (very interesting notes on p. 87-90). We fall into the trap of us “enjoying fashion and beauty”, believing we’re agents instead of victims, but we aren’t being creative with our bodies or having fun with them: we feel at fault for not matching up to the current, impossible to reach imagery. We take for granted that looking good for ourselves is going to make us feel good, find faults in our bodies and say that it makes us feel better, more in control, to improve them.

Review

I generally liked the book, but sometimes I thought it was a bit too long. Many of the important points are already made in the introduction, and the rest of the chapters are more stories and references supporting the initial points. Worse yet, I sometimes found those arguments or stories not completely believable or convincing (eg. using controversial material like some Harry Harlow experiments or Victor of Aveyron‘s story to support her points). In other cases, some relatively bold claims were not backed up by references, which made me feel could be not representative or poorly-researched or, at least, made them weaker because of a lack of context.

However, the book is well written and made me reconsider several things, which is what books like this should do. Recommended if you’re interested in psychology or if you find it intriguing to learn about our relationship to our physical bodies. Although I skipped them in the summary, some of the stories (like the man who didn’t want to have legs) are pretty mind-blowing and interesting in themselves.

As a long-time VIM user, I feel it’s my duty to make a micro-introduction to Emacs to VIM users (skip this whole paragraph if you’re not one of them). Emacs is so different than VIM that the comparison doesn’t even make complete sense, but Emacs does have many sweet, sweet features that might tempt VIM users. And let me make this clear: Emacs, in its default configuration, is rubbish. If you don’t like the idea of customising your editor, learning about it, discovering new tricks, “plugins” and shortcuts and maybe even writing your own extensions… use a different editor (eg. I find VIM way better than Emacs on the default configuration). Likewise, if you don’t learn VIM properly and don’t learn the gazillion shortcuts to fly around your code while you stay on the home row… use a different editor. With that out of the way…

A lot of what I’ve learned lately I’ve learned from a handful of websites and Twitter accounts, listed here:

• EmacsWiki: you probably already know this one, but it’s pretty useful for a variety of reasons.
• EmacsRocks / @Emacsrocks: it’s a series of screencasts showing off cool, advanced Emacs features. Each screencast is very short and focused on one thing. Instant awesome.
• EmacsRookie / @EmacsRookie: a blog with articles about different Emacs trips & tricks and features. More geared towards beginners (but my impression is that many people stay “beginners” of Emacs for quite a long time).
• Steve Yegge described “10 Specific Ways to Improve Your Productivity With Emacs“. In particular, I’d recommend making Caps-Lock behave as an extra Control key (I didn’t swap, I just have one more Control key), invoke M-x without the Meta key (both C-x C-m and C-c C-m) and being comfortable with the buffer commands. For navigation, apart from incremental search, you can also use ace-jump.
• Christian Johansen has an interesting intro article to Emacs Lisp.
• Other Twitter accounts worth following are @emacs_knight, @dotemax and @learnemacs.

In particular, things I have learned that I thought would be cool to share:

• The zenburn colour theme. I didn’t really like any of the colour themes that come with Emacs. And although I did see solarized, I thought it looked like crap on Emacs (very different from the screenshots, maybe it only works properly on Emacs 24?).
• hippie-expand is a pretty cool completion system, familiarise yourself with it.
• If you code Perl, you should be using cperl-mode, not the default Perl mode.
• If you code Javascript, you should be using js2-mode, not the default Javascript mode. Also have a look at my js2-mode configuration, you might want to do some of the same tweaks.
• If you have to do anything with XML, make sure you use nxml-mode, including its awesome feature to validate an XML document against a schema.
• yasnippet. Very cool snippet system. Just have a look at the EmacsRocks screencast on yasnippet.
• key-chord. Allows you to assign shortcuts to “key chords” (two keys pressed at the same time). Very comfy esp. if you miss some VIM shortcuts and want certain operations more VIM-like. Also seen on EmacsRocks, and again just check out the EmacsRocks screencast on key-chord.
• And speaking of VIM, have a look at iy-go-to-char, again seen in EmacsRocks (on episode 4). Hint: this works best when combined with key chords.

And last but not least, I have been writing an Emacs major mode for editing AsciiDoc documents (it currently only implements syntax highlighting, which I think is the most important part of a format like AsciiDoc). For that I basically followed the major mode tutorial and then tweaked the multi-line region matching code (for code blocks and such) by setting the font-lock-extend-region-functions variable to a function that appropriately extends the region to be highlighted. If you’re interested, just have a look at my function asciidoc-font-lock-extend-region, essentially copied from some other mode. As a last tip for writing syntax highlighting for major modes, don’t miss re-builder, it’s pure gold for testing your regular expressions!

EDIT: Manuela wrote another, easier to read summary.

Escaping flatland

The methods in this book work to increase the number of dimensions that can be represented on plane surfaces and the data density. Nearly every escape from flatland demands an extensive compromise, trading off one virtue against another. Even our language often lacks capacity to communicate a sense of dimensional complexity. Some design strategies are found again and again (examples of over 380 years of sunspot data analysis). These design strategies are surprisingly widespread, albeit little appreciated, and occur independently of the content of the data.

Massive Java railroad line example on p. 24-25. The train diagonals cleverly multiple-function, recording six variables at once (p. 26). Example of criminal activity for a trial on p. 30-31. The chart invites reading both horizontally and vertically. The eyes detect curious patterns, which make these displays persuasive and memorable. Visual displays of information encourage a diversity of individual viewer styles and rates of editing, personalising, reasoning and understanding. Unlike speech, visual displays are simultaneously a wideband and a perceiver-controllable channel.

We envision information to reason about, communicate, document and preserve that knowledge. Chartjunk on p.34: data-thin, uncontextual graphs. Its promoters imagine numbers to be dull and tedious, requiring ornament. If numbers are boring, you got the wrong numbers. The audience might be busy or eager to get on with it, but not stupid. Chartjunk looks more like a poster, meant to be looked at from a distance (thin data density).

Micro/macro readings

Detail cumulates in coherent structures. Simplicity of reading derives from the context of detailed and complex information, properly arranged. To clarify, add detail. Stem-and-leaf plots of statistical analysis also rely on micro/macro design (examples on p. 46-47).

We thrive in information-thick worlds because of our marvellous and everyday capacities to select, edit, single out, structure, highlight, group, … Visual displays rich with data are not only an appropriate and proper complement to human capabilities, but also such designs are frequently optimal. If the visual task is contrast, comparison and choice, then the more relevant information within eyespan, the better. Low-density requires visual memory, a weak skill. High density also allows viewers to select, narrate, recast and personalise data for their own uses.

What about information overload? The question misses the point. Clutter and confusion are failures of design, not attributes of information. Interesting quote on typography on p. 51. The deepest reason for displays that portray complexity and intricacy is that the worlds we seek to understand are complex and intricate.

Layering and separation

This technique is one the most powerful devices for reducing noise and enriching the content of displays. The various elements interact, creating non-information patterns and texture simply through their combined presence (1 + 1 = 3 or more). Colour effortlessly differentiates between annotation and annotated (example on p. 54). What matters is the proper relationship among information layers (example of old + improved design on p. 54-55). For tables, try to do without rules altogether, only use when absolutely necessary. Example of map (good and bad) on p. 58. Example of (non-)dull background on p. 59. Notes on how 1 + 1 = 3 can also be applied to noise on p. 61-62. Example of use of colours (another bad + good design) on p. 63.

Information consists of differences that make a difference. A fruitful method for the enforcement of such differences is using layering and separation.

Small multiples

Quantitative reasoning is based on “compared to what?”. Small multiples answer by visually enforcing comparisons of changes, of the differences among objects, and the scope of alternatives. Information slices are positioned within the eyespan, so that viewers make comparisons at a glance. Example of drawing a Kana character on p. 69. Simultaneous two-dimensional indexing of the multiplied image, flatland within flatland, significantly deepens displays with little added complication in reading.

Colour and information

Example of Swiss mountain map on p. 80. Fundamental uses of colour in information design: label (colour as noun), measure (as quantity), represent or imitate reality (representation), enliven or decorate (beauty). Principles to minimise colour damage: (1) pure, bright colours have loud, unbearable effects when they stand unrelieved over large areas adjacent to each other, but can work very well when used sparingly on or between dull background tones; (2) placing of light, bright colours mixed with white next to each other usually produces unpleasant results, esp. if the colours are used for large areas; (3) large area background or base-colours should do their work most quietly, allowing the smaller, bright areas to stand out most vividly (strongly muted colours, mixed with grey, provide the best background for the coloured theme).

What palette of colours should we choose to represent and illuminate information? Use colours in nature (familiar and coherent, possessing a widely accepted harmony to the human eye), esp. those on the lighter side such as blues, yellows, and greys of sky and shadow. Great examples on p. 90.

In the ocean map, quantities are shown by a value scale, progressing from light to dark blue. Colour rainbows confuse viewers to mumbling colour names and the numbers they represent (“To see is to forget the name of the thing one sees”). Colours are sensitive to context. In the ocean map, contours (which are very helpful) are labelled with depth measurements. Edge lines allow very fine value distinctions, increasing scale precision. Example of bad map/good colour on maps on p. 94-95.

Narratives of space and time

Example of bad/good train schedule on p. 104-105. Space-time grids have a natural universality, with nearly boundless subtleties and extensions. Great, assorted examples on p. 110-111. Example of “tale of two cities” on p. 112-113.

Final notes

I’m aware that this summary is not very useful if you can’t see the different diagrams being examined, but it’s partly for myself :-) Anyway, if you like the ideas in the book, go buy it, it’s a great book in a big format, with really nice paper and full of very interesting examples of both good and bad information design.

But enough with the reasons. It’s starting to look like it was a pretty useful mini-project. Not just because I learned a bit more Javascript, the excellent express web development framework and other things, but also because the result itself, even though it didn’t take long to develop (and it was pretty fun, even!), feels useful. It feels like a nice place to put all my notes, TODOs, random ideas for projects, etc. A similar feeling of freedom as when I started using my first Moleskine. Not that I would ditch paper for computer-anything, but it’s useful and freeing in its own way, for specific purposes.

About the technology, I used the Markdown format for the pages thanks to the markdown-js library (it’s really nice that the module has an intermediate tree format that you can parse to add your own stuff before converting to HTML, like e.g. wikipage links!), express for the whole application structure and js-test-driver + jsautotest + a bit of syntax sugar from Sinon.js for the tests (but looking forward to trying out Buster.js when it’s released!). The deployment to Joyent’s Node.js SmartMachine was reasonably easy. Actually, it was pretty easy once I figured the following:

• You must not forget to listen in the correct port, with server.listen(process.env.PORT || 8001)
• There are a couple of pretty useful Node.js-related command-line utilities to check logs, restart applications and so on
• The configuration of the application can be done via npm config, see npm integration on Joyent’s Wiki

If you’re curious to see the code, play with it or use it yourself, take a peek to the Wiki-Toki repository on GitHub. Happy hacking!

I had been thinking of trying out GNOME 3 since it was released. For a number of reasons, I only managed to give it a try a couple of days ago. I normally use KDE 4, but wanted to see how GNOME was doing these days, and wanted to see if it was something I could maybe switch to. I have to say I quite liked some of the stuff I saw, but I don’t think I can switch. My reasons:

• Language switcher keyboard combination: I just couldn’t find any combination I could use. Everything conflicted with some other combination I use (esp. in Emacs). Having to change the keymap by clicking on the top bar didn’t sound sane to me.
• Order of the OK/Cancel buttons: even if I switched, I would probably use a combination of systems. Having to train my brain to look for the buttons in a different position seemed like too much.
• Rhythmbox seemed plain, clunky and hard to use. It seemed hard for me to do what I wanted, plus it crashed consistently while trying to listen to some podcast.
• I kind of like the idea of how workspaces work (even though I have to radically change the way I use them to adapt to them), but for me it’s too much that both (a) closing the last window makes the workspace disappear and (b) you can’t create workspaces “above”. That is a deal-breaker for me.
• Can’t create workspaces on the right or left? I could get used to that probably, but it added up to my frustrations with GNOME 3 workspaces.
• Constant repainting issues.
• Can’t make sense of the window traversing. Let’s say I have two virtual desktops, one with a browser and another one with two terminals. The focus is on one of the terminals, and I want to go to the other terminal (with the keyboard, of course). If I just press Ctrl-Tab GNOME takes me to the web browser in the other desktop! If I want to go to the other terminal, I have to press Ctrl-Tab, Shift-Ctrl-Tab to go back to the terminal, arrow down to see all the terminal windows, arrow right to go to the next terminal. It’s even worse when I have Opera in one virtual desktop (maximised) with the error console in the same desktop. As Opera is maximised, I can’t even click with the mouse, so the only way to switch to the error console I can think of is doing the dance described above. Am I missing something, is this for real? EDIT: I was told about Ctrl-` (changes between windows of the same application). Cute attempt, but I don’t think I can get used to thinking if I have to use Ctrl-TAB or Ctrl-`. So that remains “impossible to use” for me.

I wonder if some GNOME user can shed light on some of those issues, although it doesn’t seem like I can find a solution for all my frustrations :-)

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.