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!

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.

The other news is that finally the Opera QA blog is online, and has the first non-hello-world-article (written by yours truly), “Continuous Integration: Team Testing”. I’m very excited about this, because it’s the first time I’ll participate directly in a company blog, and because the IT world needs more (and better) QA, so hopefully we’ll be able to spread the word and make the world a better place :-D

It sounds pretty scary, but actually it’s really safe and easy to use: you just copy some files into your memory card, and ask the camera to upgrade the firmware via some menu option. The awesome part is that it only “upgrades” a copy in memory, so if you simply turn off the camera, the next time everything is back to normal. Of course there are options to load it on startup if you’re happy with it.

The goodies: saving in RAW format, some new menu options, more information on the OSD, configurable OSD, BASIC scripting, and even games (Sokoban and Reversi). One of the features that caught my attention in the article was a special mode for motion detection, that apparently works well for making pictures of lightning strikes. And it’s actually a user-written script, how awesome is that?

I haven’t played that much with it yet, but I have tried and it works as advertised (YMMV). I can’t wait to use it more, and maybe even try some silly BASIC program.

Thanks a lot Arve! ;-)