Learning through Writing

Writing To Learn And Why It Matters

In this article, Boser describes the process of writing as a means to learn. He discusses how the process of engagement with the text, rather than simply reading, helps with internalizing the content. He claims that one of the benefits of writing things down is it brings you up into metacognition (awareness of thought process). From there, the process of noticing allows you to make judgement calls about what you’re learning.

This noting of deeply engaging with a text reminds me of a group Torah study session, whereby people read the text and talk about it. It’s not a surface level “Oh, this is what happened”, but rather goes much deeper. It’s common for people to use metaphor or bring in a modern context as a way of evaluating and challenging the reading. While this is an oral process, it’s still a fascinating way to apply to studying.

This reminded me of Gary Barnhardt, who has done several screencasts on computer programming. I’ve always really admired his precision of thought. I think a large part of his success in this area is this metacognition. He pays close enough attention to software (which appears maddening from the outside!) to notice it’s underlying foibles. I think this process of observing and reflecting allows him a lot of clarity when thinking through software design in general.

Another such thinker is Trevor Foucher, who I worked with at Google. He eventually wrote a book called the Art of Readable Code, which goes into various patterns of good software design. He was always a thoughtful code reviewer, and I think this cycle of seeing mistakes, noting them, noting the resulting fix and then iterating on it are the genesis of both his book and also the quality of his review.

Taking a retrospective look at mistakes or learning is also reminiscent of Sydney Dekker’s book, “The Field Guide to Understanding ‘Human Error’“. In that book, he describes how industries such as airlines have very rigorous root-cause analysis when problems arise. The result is a reduction in error. This connects to post-incident analysis practices in software engineering. I’m not certain how much this applies in this context, but I know from my professional life, I’ve certainly thought “I’m not going to do this because I don’t want to have to answer for it if something inevitably goes wrong”. This self-induced dampening effect may also be a reason why there’s a reduction of errors.