Skip to main content

Taking Note


In Something of Note, a post about Karo Stoltzenburg and Neil Younger's recent workshop on note-taking, I wrote:
I am especially inspired to see whether I can distil any conventions from my own note-taking ...  I favour plain text for note-taking on the computer and I have established conventions that suit me for that. I wonder are any conventions present in multiple of the approaches that I use?
Since then I've been collecting fieldstones as I observe myself at work, talking to colleagues about how they see my note-taking and how it differs from theirs, and looking for patterns and lack of patterns in that data.

Conventions

I already knew that I'd been revising and refining how I take notes on the computer for years. Looking back I can see that I first blogged about it in The Power of Fancy Plain Text in 2011 but I'd long since been crafting my conventions and had settled on something close to Mediawiki markup for pretty much everything.  And Mediawiki's format still forms the basis for much of my note-taking, although that's strongly influenced by my work context.

These are my current conventions for typed notes:
  • * bullet lists. Lots of my notes are bullets because (I find) it forces me to get to "the thing"
  • ... as a way to carry on thoughts across bullets while preserving the structure
  • > for my side of a conversation (where that is the context), or commentary (in other contexts)
  • / emphasis
  • " for direct quotes
  • ---- at start line and end line for longer quoted examples, code snippets, command line trace etc
  • ==, ====, ==== etc for section headers
  • +,-,? as variant bullet points for positive, negative, questionable
  • !,? as annotations for important and need-to-ask

These are quick to enter,  being single characters or repeated single characters. They favour readability in the editor over strict adherence to Mediawiki, e.g. I use a slash rather than  repeated single quotes for emphasis because it looks better in email and can be search-replaced easily.

I am less likely to force a particular convention on paper and I realise that I haven't put much time into thinking about the way I want to take notes in that medium. Here's what I've come up with by observation:
  • whole sentences or at least phrases
  • quotation marks around actual quotes
  • questions to me and others annotated with a name
  • starring for emphasis
  • arrows to link thoughts, with writing on the arrows sometimes
  • boxes and circles (for emphasis, but no obvious rhyme or reason to them)
  • structure diagrams; occasional mind map
  • to-do lists - I rarely keep these in files
  • ... and I cross out what I've done
  • ... and I put a big star next to things I crossed out that I didn't mean to

Why don't I care to think so hard about hand-written notes? Good question. I think it's a combination of these factors: I don't need to, I write less on paper these days, the conventions I've evolved intuitively serve me well enough, it is a free-form medium and so inventing on the fly is natural, information lodges on paper for a short time - I'll type up anything I want to keep later.


Similarities and Differences

I want to get something of that natural, intuitive spirit when typing too, although I'm not expecting the same kind of freedom as a pen on paper. What I can aim for is less mediation between my brain and the content I'm creating. To facilitate this I have, for example:
  • practised typing faster and more accurately, and without looking at my fingers
  • learned more keyboard shortcuts, e.g. for navigating between applications, managing tabs within applications, placing the cursor in the URL bar in browsers, and moving around within documents
  • pinned a set of convenient applications to the Windows taskbar in the same order on all of the computers I use regularly
  • set up the Quick Access Toolbar in Office products, and made it the same across all Office products that I use
  • made more use of MRU (most recently used) lists in applications, including increasing their size and pinning files where I can

With these, for example, I can type Windows-7, Alt-5 to open Excel and show a list of recently-used and pinned files. Jerry Weinberg aims to record his fieldstones within five seconds of thinking of them. I don't have such strict goals for myself, but I do want to make entering my data as convenient as possible, and as much like simply picking up a notepad and turning to the page I was last working on as I can.

That's one way I'm trying to bring my hand and typed note-taking closer together in spirit, at least. There are also some content similarities. For instance, I tend to write whole sentences, or at least phrases. Interestingly, I now see that I didn't record that in my list of conventions for typed notes above. Those conventions concentrate solely on syntax and I wonder if that is significant.

I don't recall an experiment where I tried hard not to write in sentences. The closest I can think of is my various attempts to use mind maps, where I find myself frustrated at the lack of verbal resolution that the size of the nodes encourages - single words for the most part. Again, I wonder whether I don't trust myself enough to remember the points that I had in mind from the shorter cues.

In both hand and typed notes, I overload some of the conventions and trust context to distinguish them. For example, on paper I can use stars for emphasis or specifically to note that something needs to be considered undeleted. On screen I'll use ? for questions and also uncertainty. I also find that I rarely start numbered lists because I don't want the overhead of going back and renumbering if I want to insert am item into the list,

Something else that I do in both cases is "layering". In Something of Note I mentioned that I'd shown my notes to another tester and we'd observed that I take what I've written and add "layers" of emphasis, connections, sub-thoughts, and new ideas on top of them. (Usually I'll do this with annotations, or perhaps sidebars linked to content with arrows.)

Similarly, one of my colleagues watched me taking notes on the computer during a phone call and commented on how I will (mostly unconsciously) take down points and then go back and refine or add to them as more information is delivered, or I have commentary on the points I've recorded.

There are some differences between the two modes of note-taking. One thing that I notice immediately is that there is no equivalent to doodling in my computer-based notes where my hand-written notes are covered in doodles. I don't know what to conclude from that.

Also, I will use different textual orientations in my written notes, to squeeze material into spaces which mean it is physically co-located with text that is related to it in some way. I don't have that freedom on screen and so any relationships have to be flagged in other ways, or rely on e.g. dynamically resizing lists to add data - something that's less easy on paper.

Where I am aggregating content into a single file over time - as I do with my notes in 1-1 meetings - I almost always work top-down so that the latest material is at the bottom and I can quickly scroll up to get recent context. (I find this intuitive, but I know others prefer latest material at the top.)

Because I don't aggregate content over time in the same way on paper, I don't have quite the same option. I write all of my notes into the same notebook, regardless of context (though I may start a new page for a new topic) so I don't have lots of places to look for a particular note that I made.

Within a notebook, I can flick back through pages to look for related material. I date-stamp my notebooks with a sticker on the front so that I can in principle go back to earlier books, but I rarely do either over periods anything longer than a handful of days.

One other major difference - a side-effect, but a significant one - is that I can easily search my computer notes.

Choosing

I found that there are situations where I'll tend to use one or other of the note-taking techniques, given free choice. I prefer hand-written notes for:
  • technical meetings
  • meetings where it's less important that I maintain a record
  • meetings where typing would be intrusive or colleagues have said they find it distracting
  • informal presentations, our Team Eating brown bag lunches, local meetups
  • face-to-face job interviews
  • team meetings
  • to-do lists
  • when I need to make diagrams
  • when I don't have access to my computer

Whereas computer-based notes tend to be used for:
  • 1-1 (whether I'm the manager or the report)
  • writing reports
  • writing testing notes (including during sessions)
  • writing blogs
  • where I'm trying to think through an idea
  • when I want to copy-paste data from elsewhere or use hyperlinks
  • when I want to not have to write up later
  • when I want to be able to continue adding content over an extended period of time 

And there are occasions where I use both in tandem. For example, when engaged in testing I'll often record evidence in screenshots and drop the file location into my notes.

I might sketch a mind map on paper to help me to explore a space, then write it up in an editor because that helps me to explore the nature of the relationships.  This is probably a special case of a more general approach where I'll start on paper and switch to screen when I feel I have enough idea - or sometimes when I don't - because editing is cheaper on the computer. From Tools: Take Your Pick:
Most of my writing starts as plain text. Blog posts usually start in Notepad++ because I like the ease of editing in a real editor, because I save drafts to disk, because I work offline ... When writing in text files I also have heuristics about switching to a richer format. For instance, if I find that I'm using a set of multiply-indented bullets that are essentially representing two-dimensional data it's a sign that the data I am describing is richer than the format I'm using. 
In particular, I will aggressively move to Excel for tabular data. (And I have been refining the way I use Excel for quick one-off projects too; I love tables.)

Reflections

I am an inveterate note-taker and I think I'll always prefer to record more rather than less. But when it comes to the formatting, I'll always prefer less over more. For me, the form should serve the content and nothing else, and a simpler format is (all other things being equal) a more portable format.

It appears that I'm happy to exploit differences where it serves me well, or doesn't disadvantage me too much - I clearly am not trying to go to only hand-written or only computer-based notes. But I do want to reduce variation where it doesn't have value because it means I can switch contexts without having to switch technique and that means a lower cost of switching, because I might already be switching domain, task, type of reasoning etc. In a similar spirit, I am interested in consolidating content. I want related notes in the same place by default.

But I'm not a slave to my formatting conventions: something recorded somehow now is better than nothing recorded perfectly later. I will tend to do the expedient over the consistent, and then go back and fix it if that's merited. I very deliberately default to sticking to my conventions but notice when I find myself regularly going against them, because that indicates that I probably need to change something.

Right now I am in the process of considering whether to change from ---- at the start and end of blocks to using three dashes and four dashes at start and end respectively. Why? Because sometimes I need to replace the blocks with <pre> and </pre> tags for the wiki. Marking up the start and end with the same syntax doesn't aid me in search-replacing.

When I am trying to introduce some new behaviour, I will force myself to do it. If I fail, I'll go back and redo it to help to build up muscle memory. I think of this as very loosely like a kata. For example, I was slower at typing for a while when I started to type in a more traditional way, but I put up with that cost in the belief that I would ultimately end up in a better place. (And I did.)

I think that my computer note-taking is influencing the way that I write non-note content. To give one illustration: over the years I have evolved my written communications (particularly email) to have a more note-like structure. I am now likely to write multiple one-sentence paragraphs, pared back to the minimum I think is necessary to get across the point or chain of reasoning that I want to deliver.

Likewise, I try to write more, shorter paragraphs in my blog, because research I've read, and my own experience, is that this is a more consumable format on screen.  (After seeing how much content I'd aggregated for this blog post, I considered splitting it too.)

I use text files as repositories of related information, but I also sometimes have a level of organisation above the file I'm working in. I'm recruiting as I write this. If, after I review a CV, I want to talk to the candidate, I start a text file in the folder I'm maintaining for this round of recruitment. My notes on the CV go there, as do questions I'll ask when we speak. On the phone I'll type directly into the file, recording their answers, my thoughts on their answers, new questions I want to ask and so on. At the end of the interview, I'll briefly review and note down my conclusions in the file too.

The same technique applies to my team. I have weekly 1-1 with my team and an annual review cycle. I make a folder per person, inside that a folder per cycle and, inside that I have a text file, called Notes.txt. In 1-1 I will enter notes while we talk. Outside of 1-1 I'll drop thoughts, questions, suggestions and so on into the file in preparation for our next meeting. Over time, this becomes an historical record too, so I can provide longitudinal context to discussions.

This stuff works for me - or at least, is working for me right now better than anything else I've tried recently and given the kinds of assessments I've made of it - but none of it is set in stone. My overarching goal is to be efficient and effective and I'm always interested in other people's conventions in case I can learn something that helps me to improve my own.
Image: https://flic.kr/p/iXmQCZ

Comments

Popular posts from this blog

Can Code, Can't Code, Is Useful

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "If testers can’t code, they’re of no use to us" My first reaction is to wonder what you expect from your testers. I am immediately interested in your working context and the way

Testing (AI) is Testing

Last November I gave a talk, Random Exploration of a Chatbot API , at the BCS Testing, Diversity, AI Conference .  It was a nice surprise afterwards to be offered a book from their catalogue and I chose Artificial Intelligence and Software Testing by Rex Black, James Davenport, Joanna Olszewska, Jeremias Rößler, Adam Leon Smith, and Jonathon Wright.  This week, on a couple of train journeys around East Anglia, I read it and made sketchnotes. As someone not deeply into this field, but who has been experimenting with AI as a testing tool at work, I found the landscape view provided by the book interesting, particularly the lists: of challenges in testing AI, of approaches to testing AI, and of quality aspects to consider when evaluating AI.  Despite the hype around the area right now there's much that any competent tester will be familiar with, and skills that translate directly. Where there's likely to be novelty is in the technology, and the technical domain, and the effect of

Testers are Gate-Crashers

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Testers are the gatekeepers of quality" Instinctively I don't like the sound of that, but I wonder what you mean by it. Perhaps one or more of these? Testers set the quality sta

Am I Wrong?

I happened across Exploratory Testing: Why Is It Not Ideal for Agile Projects? by Vitaly Prus this week and I was triggered. But why? I took a few minutes to think that through. Partly, I guess, I feel directly challenged. I work on an agile project (by the definition in the article) and I would say that I use exclusively exploratory testing. Naturally, I like to think I'm doing a good job. Am I wrong? After calming down, and re-reading the article a couple of times, I don't think so. 😸 From the start, even the title makes me tense. The ideal solution is a perfect solution, the best solution. My context-driven instincts are reluctant to accept the premise, and I wonder what the author thinks is an ideal solution for an agile project, or any project. I notice also that I slid so easily from "an approach is not ideal" into "I am not doing a good job" and, in retrospect, that makes me smile. It doesn't do any harm to be reminded that your cognitive bias

Play to Play

I'm reading Rick Rubin's The Creative Act: A Way of Being . It's spiritual without being religious, simultaneously vague and specific, and unerring positive about the power and ubiquity of creativity.  We artists — and we are all artists he says — can boost our creativity by being open and welcoming to knowledge and experiences and layering them with past knowledge and experiences to create new knowledge and experiences.  If that sounds a little New Age to you, well it does to me too, yet also fits with how I think about how I work. This is in part due to that vagueness, in part due to the human tendency to pattern-match, and in part because it's true. I'm only about a quarter of the way through the book but already I am making connections to things that I think and that I have thought in the past. For example, in some ways it resembles essay-format Oblique Strategy cards and I wrote about the potential value of them to testers 12 years ago. This week I found the f

Meet Me Halfway?

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answer would be almost meaningless and certa

Test Now

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When is the best time to test?" Twenty posts in , I hope you're not expecting an answer without nuance? You are? Well, I'll do my best. For me, the best time to test is when there

Rage Against the Machinery

  I often review and collaborate on unit tests at work. One of the patterns I see a lot is this: there are a handful of tests, each about a page long the tests share a lot of functionality, copy-pasted the test data is a complex object, created inside the test the test data varies little from test to test. In Kotlin-ish pseudocode, each unit test might look something like this: @Test fun `test input against response for endpoint` () { setupMocks() setupTestContext() ... val input = Object(a, OtherObject(b, c), AnotherObject(d)) ... val response = someHttpCall(endPoint, method, headers, createBodyFromInput(input) ) ... val expected = Object(w, OtherObject(x, y), AnotherObject (z)) val output = Object(process(response.getField()), otherProcess(response.getOtherField()), response.getLastField()) assertEquals(expected, output) } ... While these tests are generally functional, and I rarely have reason to doubt that they

A Qualified Answer

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn ,   Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Whenever possible, you should hire testers with testing certifications"  Interesting. Which would you value more? (a) a candidate who was sent on loads of courses approved by some organisation you don't know and ru

README

    This week at work my team attended a Myers Briggs Type Indicator workshop. Beforehand we each completed a questionnaire which assigned us a personality type based on our position on five behavioural preference axes. For what it's worth, this time I was labelled INFJ-A and roughly at the mid-point on every axis.  I am sceptical about the value of such labels . In my less charitable moments, I imagine that the MBTI exercise gives us each a box and, later when work shows up, we try to force the work into the box regardless of any compatiblity in size and shape. On the other hand, I am not sceptical about the value of having conversations with those I work with about how we each like to work or, if you prefer it, what shape our boxes are, how much they flex, and how eager we are to chop problems up so that they fit into our boxes. Wondering how to stretch the workshop's conversational value into something ongoing I decided to write a README for me and