Instead of a special sequence of characters, type a caret and a word, such as ^here. That's a block reference that marks the preceding paragraph with a label. You can jump to that mark with any internal link, such as [[Your file#^here]], but I use it in the file itself by creating a frontmatter field called marks with the value [[#^here]]. That gets rendered as a link which when clicked jumps to the ^here mark.

I put ^here on a blank line between paragraphs. Jumping to it briefly highlights the preceding paragraph, but I know the mark is a separator and resume editing below that point.

If you make the marks field a list, you can include multiple links in one frontmatter field. You can also create a template that works with both the Templates core plugin or the Templater community plugin:

---
marks:
  - '[[#^here]]'
---
^here

That will add the link to the marks field, creating the field if it doesn't exist, and add ^here wherever your cursor is.

Be warned that not all Markdown renderers recognize Obsidian's ^ syntax. While exporting from Obsidian won't render the in-document marks, other Markdown formatters might, and I've occasionally ended up with stray ^here paragraphs.

Obsidian has a huge number of community plugins. Plugins support custom HTML and logic, so I could have rebuilt the web apps as dedicated plugins, but I didn't want to make a custom plugin for each tool, just one plugin that bridged between Obsidian and my web apps. I've dabbled a little in making Obsidian plugins, but since I could define the solution clearly and was more interested in the end product than in the process of building, I tried my hand at vibe-coding and asked Claude to make a plugin. You can find it here. I reviewed the code enough to be familiar with it, so if you have suggestions for improvements, feel free to open an issue or pull request.

At heart, all the plugin does is transmit data back and forth between the Obsidian note and the web app. It loads the web app in an iframe and passes data to it in a message. Web apps pass messages back with data that the plugin saves to the file. The web app can be the whole tab, in which case the note's YAML frontmatter is passed to the app as JSON, or the web app can be sourced from a code block, and only the code block's YAML content is given. More details on the message-passing protocol are in the README.

The plugin supports multiple web apps. Configure names and URLs in the plugin's settings, then specify which web app to load by adding a webapp key whose value is the name you gave the web app. There is a toolbar with a "Save" button to ask the web app for the current state. When the web app is sourced from a file, you can switch to a Markdown view. When sourced from a code block, you can specify the height of the iframe.

It can also be used in the mobile version of Obsidian.

I've been using the plugin here and there for about a month, so it's far from battle-tested, but in my experience the weak point is my web apps, not the plugin. I'm not 100% convinced this is a good idea. The plugin allows web apps to read data from and write data to the Obsidian notes you use it in, so only use web apps you trust. You should also have Obsidian Sync, Git, or some other version control system that backs up files you use with the plugin, since a web app that returns empty values will remove data from the file. If you have security concerns, definitely email me.

Do you have other techniques for managing specialized documents across devices? I'm all ears.

I don't want to read a novel where most of the words are written by an LLM, even if a human designed the novel at a high level. It feels gross. I think this is the reason. The statistical profile of LLM writing is close to the normal. That's literally how LLMs work. They sample from a distribution that captures a median way of writing. I simply don't want my mind pushed towards the statistically normal when I am reading fiction. That's the exact opposite of what I want from the experience.

I may finally read The End of Average, now that LLMs have given us The Revenge of Average. Average output is acceptable for computer code, for which the purpose is to get a computer to operate in a specific way, but the human central processor works differently. We tend to ignore sameness and remember novelty. That's the root of a lot of our cognitive biases.

I've used LLMs as research assistants for fiction, and sometimes they can break me out of my self-imposed mental boxes, but any time I've accepted their offer to write a sample for a story, I've been profoundly bored by the result. Possibly my prompts could be better. I learned a little about writing from asking an LLM to write a simple scene in the styles of various authors, in order to learn more about pacing narrative prose, and while the scenes were readable, they weren't interesting. Same for a couple vignettes I've generated to entertain my kids with a scene of a Muppet exploring space or under the ocean. LLMs are competent language calculators, but they can't intrigue. They have no personality. They can nerd out about anything, and thus can't obsess over something to the exclusion of everything else.

Chris's post gives me a much better appreciation for how much writing is, at heart, about connecting with another human. We want to know that a person thought it was worth putting these words together, was willing to spend the time creating this story, sharing these characters, composing this sentence, and that when challenged about what they've written will defend it and maybe, in so doing, teach us something valuable. Reading fiction isn't about assembling information; it's about gaining understanding. Sometimes wisdom comes from juxtaposing information, but more often it comes from the enigmatic other, the person across the table or at the other end of the fiber optic cable. It comes from someone who's had skin in the game and had to make difficult choices.

My hope in the era of LLMs is that we as humans learn to find each other more fascinating.

Local-first software is distinct from local-only software. My local-only apps require the user to transfer state between devices, but local-first software is local first, replication second. As far as I've learned so far, that typically means having a server that can relay state changes, often using CRDTs. I've started listening to the localfirst.fm podcast to learn more. There's also a Local-First Conf and the website lofi.so. A related term I like is "LEAF computing", which stands for Local Execution, Autonomous, and Federated (I've also heard Local, Encrypted, Autonomous, and Federated). The term "LEAF computing" stands in contrast with "cloudy computing".

I treasure the values of the local-first software movement, specifically giving users ownership of their data, the ability to run software fully offline, much lower UI latency, and using local compute resources rather than servers in a data center. It's not the right architecture for many types of software, among them e-commerce and social media platforms. The former needs stronger authorization controls than local-first software can guarantee, and the latter operates at larger scales than can easily run locally (though there is Scuttlebutt).

Given those constraints, much of the local-first software I see advertised appears to be note-taking software. Obsidian is the clearest example, used for managing images and Markdown notes. BrainFrame looks similar. Allume captures whiteboard-style notes. Somewhere I saw a recipe tracker. Those uses are great, but I'm more interested in how local-first software can go beyond the zettelkasten. The best examples I know are Actual Budget, which tracks home finances, and some music players.

Do you use local-first software? Anything you'd recommend, either for using directly or for learning from? If so, email me!

foreignObjects

The first was in Causation, my simple cause-and-effect diagrammer. It renders everything in an SVG, and makes the text in nodes editable by embedding HTML using foreignObject. Turns out Safari has multiple foreignObject bugs. I ran into one which rendered every foreignObject in the wrong location, and another that rendered the elements on top of the elements that cover the SVG.

I fixed the positioning problem by calculating view transforms myself. I haven't yet fixed the overlay problem with foreignObjects, but I think I'll move the HTML content into a purely HTML layer over the SVG, then position elements absolutely. Most of the UI is an infinite canvas, so some glitches over the toolbar at the top are minor.

grid-template-columns and grid-template-rows

On another project, I used CSS's grid-template-columns and grid-template-rows to create a square grid:

.grid {
  display: grid;
  grid-template-columns: repeat(var(--column-count), 1fr);
  grid-template-rows: repeat(var(--row-count), 1fr);
}

The .grid DOM element can then specify its size by setting an element-level style attribute with the value --column-count: 5; --row-count: 5.

But on Safari, switching from a grid of fewer tiles to one with more tiles in the same width caused the grid to overflow its bounds:

The layout gets fixed on the next reflow. A couple suggested workarounds didn't help, so I ended up removing the CSS grid properties and instead set a percentage width for the tiles.

None of the apps are polished, nor bulletproof. I made them to learn, not just about a set of ClojureScript libraries but also about new developments in web technologies. Consider them scrappy fiddles. If you find any of them useful, let me know, and certainly report any bugs.

Here's a quick rundown of each app.

Tinycal

This is the fourth iteration of this tiny calendar. The first implementation is lost to time, but the second version (which I covered a few years ago) recreated it and just showed one year from beginning to end with buttons to export it to SVG or PNG. The third iteration let you configure the start date, end date, what day of the week to start on, which dates to show, and provided a print option. Those versions now redirect to the latest take.

The new version I built because my brother uses the exported PNG in an image editor to outline his plans for the year ahead, and I realized I could make that at least a little easier. Now Tinycal allows selecting dates and highlighting them in one of several colors. You can also add a note that labels events to the right of the calendar.

It's still a tiny calendar, so it gets crowded fast if you try to use it for scheduling, but I like it less for seeing the day-to-day obligations and more for mapping the broad strokes of the coming months, especially for seeing what weekends I have free. To help with that, the app can be saved to your phone's home screen and run as a progressive web app.

Conflict resolution diagrammer

Years ago I made a web-based diagrammer for conflict resolution diagrams, but I was never totally happy with it. Revisiting it recently to explore some tensions at work, I was pleasantly surprised to learn that CSS now has a grid layout that you can template using an ASCII diagram. That made it a lot easier to handle a more two-dimensional layout.

Most people aren't familiar with a conflict resolution diagram, so I added some documentation below the app to explain how to use it. It's easy to miss when you land on the page, so if you have design tips to improve it, send them my way.

QuizBoard

The very first real software I made was a pared-down version of Jeopardy! for a kids' study group. I implemented it in Visual Basic in junior high school and called it "Answers & Questions". It loaded categories and questions from a text file. The layout was hard-coded to an 800x600 screen resolution, so every time it was used on a higher resolution monitor, the computer's screen size had to be changed for the game to fill the screen. Eventually I made a version that scaled to screen resolution, but by then I didn't need the game and the rewrite was mostly a learning exercise.

A couple months ago I was asked for a new version, which I dubbed "QuizBoard". While Answers & Questions followed a strict Jeopardy! layout of six categories with five questions each, QuizBoard allows any number of categories, each category can have any number of questions, and each question can have multiple clues. At first I required a game to be made by editing the downloaded YAML file and re-uploading it, but that proved both cumbersome and error-prone, so I added a simple game editor.

I also added a presentation mode. Launching it opens a new window that can be shown on an external monitor and controlled from the original window. That gives the operator a chance to see all the clues on a question, as well as the answer, so they can decide if a team got the right answer.

Causation

In high school, I had to make a cause and effect diagram of the American Civil War, and I got carried away, spreading it onto multiple sheets of printer paper that I taped together into a poster. In college, I made diagrams for some of the European periods covered in freshman history, and when my classmates saw them, they asked for copies to study from. Probably if I had learned to make such diagrams sooner, I would have been interested in history sooner. I've also drawn cause and effect diagrams to explore complex systems.

Since college, I've tried a few different graphing tools for making cause and effect diagrams, but I haven't found any I've liked. Graphviz and Mermaid are text-based and easy to lose my place in. Excalidraw is more visual and manual, and arrows stay connected to boxes, but when drawing a current reality tree) I want to link edges together to denote multiple conditions that need to be true to produce an effect, and Excalidraw doesn't offer that without jumping through hoops like intermediate nodes.

I finally sat down to make something suited to my usage. It snaps nodes to a coarse grid, doesn't require drawing arrows manually, allows inserting nodes in the middle of existing links, and most importantly, lets you link edges to each other. My favorite feature is being able to move whole subgraphs, dragging all of a node's descendants or ancestors with it to make more room.

Home Electric Cost Optimizer

My father has a hybrid vehicle and was curious if he got solar panels whether he should charge the car with surplus solar power during the day or use cheaper rates from the grid at night and sell surplus solar power back to the grid. I made this calculator to explore possibilities.

There are a lot of factors in the conversion of solar irradiance to actual power output. Latitude is the main one, but it's also affected by your local climate's tendency toward cloudiness, the efficiency of the panels, the direction the panels face, and their angle. I simplified all of that by asking for max power output on the summer solstice, then scaling solar irradiance to produce that.

Making it for someone other than myself meant more back and forth communication with a "customer". The physicist in me desperately wanted to reduce units like kilowatt-hours per hour to just kilowatts, but to a layman looking at his electric bills that was less intuitive than kWh/h.

Timeliner

Another history-related project is Timeliner, which I started because I frequently find myself either surprised by how far apart different events were or how unrelated events happened at the same time. For example, I tend to forget Mozart lived during the American Revolution. To gain a better perspective, I wanted a timeline visualization tool that let me add arbitrary historical events and zoom and scroll horizontally. Probably there's a good tool for this, but I forgot to look.

Making it, I discovered there's a native HTML color element, and while the Mac color picker lets you define swatches, it pops up a new window that can lose focus to the original window, which for me caused some odd behavior.

Below are descriptions of several scripts I use on a daily basis.

Most of my scripts aren't portable. They're tailored to the specific tools I use, such as Tmux and Alfred, they often require particular libraries and environment variables, and while some are Bash, most of them favor Clojure (Babashka). Rather than sharing the scripts themselves, this post focuses on the problems that prompted them and what I automated.

ws & friends

I use Git worktrees extensively, checking out work-in-progress branches and code to review in separate folders and Tmux sessions. Here's one version of the script. My current iteration is called ws and takes two or three parameters:

ws <type> <name> [<ticket-number>]

type can be feat, fix, task, or cve. name is the name to use for the branch and Tmux session. If there's a Jira ticket associated with the work, ticket-number captures that.

ws creates a new Git branch using the given information (e.g. feature/some-branch-name-TICKET-5555), then checks out the branch in a new Git worktree and creates a Tmux session for it. It also captures the data in a couple of files local to the worktree. One is a local draft of the PR, which is Markdown but has YAML frontmatter where I specify the title of the PR, any labels, reviewers, and the ticket number. Those will be used when creating the PR (see gh-open below). Some of that information is also captured in a .workspace.yaml file, which can be used to re-launch the the Tmux session. Both .workspace.yaml and the PR file are created by ws and ignored by Git via a global gitignore.

ws creates the workspace files, but opening the workspace is performed by wso ("workspace open"), which ws invokes but which I can also invoke manually on any directory with a .workspace.yaml file. Initializing the workspace is done by wsi ("workspace initialize"), which sends the init command (see below) to the first Tmux pane in the workspace.

Similar to ws is wsc ("workspace checkout"), useful for branches that exist but for which I don't have a local worktree.

To review someone else's pull request locally, I use wsr ("workspace review"). It pulls the URL for the PR from the clipboard, fetches the PR from GitHub's API, switches to the local directory for that repo, then invokes wsc for the PR's branch.

When I'm done with a workspace, I run wsd ("workspace destroy") to check for pending changes, and if there aren't any, the script switches the Tmux client to a Tmux session that won't be deleted, deletes the Git worktree, and kills the workspace's Tmux session.

init and friends

I have an init-<repo-name> script for each repo I work in. They do all the setup for a new worktree, such as creating a Python virtual env, activating it, and installing dependencies. Most repos have a Makefile or install.sh script which does the heavy-lifting, so these init-* scripts capture what's specific to my workflow, such as using pyenv rather than some other virtual environment tool.

init is just a wrapper script that 1) inspects the Git repo to figure out which init-* script to run, 2) verifies the init-* exists, and 3) runs it. ws launches this automatically in new workspaces, but on occasion I invoke it manually.

cve

A few weeks ago I addressed a lengthy backlog of security vulnerabilities. I chose to tackle them in bulk—rather than chip away here and there—so I could focus on developing a system and encoding it in a script, smoothing the process for future fixes. The result was the script cve with several subcommands.

cve check reads the system clipboard to get the URL for a Jira ticket, parses the ticket's description, finds the name of the affected Docker image and the package that needs to be upgraded, then opens a URL to our internal artifact repository that lists the image's current vulnerabilities. Occasionally vulnerabilities have been fixed by other changes and the ticket remains open. When that happens, cve close will comment on the Jira ticket with a link to the vulnerabilities page, assign it to me, and close the ticket. If the vulnerability still exists, cve ws finds the repo that produces the affected Docker image and invokes ws cve with the CVE's ID.

cve repro builds the Docker image, then runs docker scout cves and picks out the sections mentioning the CVE's identifier. This is the most complicated subcommand. Some of the Dockerfiles need tweaks to build locally (for which I keep a set of patches), several of the images depend on other images having been built first, some images are built by specific Makefiles, and building can require particular environment variables. All that information is tracked in a data structure in the script.

cve locations runs docker scout cves with the --format sarif option, which emits JSON, then the script plucks out the buried .physicalLocation fields to get the full paths to the files that introduce the vulnerability. Where the file indicates whether the vulnerability is due to an NPM dependency, a Python dependency, or a package installed in the Docker image itself.

testit

Different projects have different ways to run tests, and even a single repo can have separate test runners for backend unit tests, frontend unit tests, and integration tests. When I want to run a single test, I never remember whether the runner wants a line number or the name of the test. Rather than trying to keep it all straight, I use testit.

The script takes a path and line number. It checks the path against several regex patterns to find the function that can run the test. For test runners that take a path and line number, the function calls babashka.process/shell with the proper directory, environment variables, and shell command. For test runners that want the name of a test, the script first parses the test file by shelling out to tree-sitter with tree-sitter parse <path> --xml, then it finds the appropriate concrete syntax tree expression by pattern-matching with Meander. For example, in a Python unit test suite, it looks for methods starting with test_ and classes starting with Test, picking the last one that's above or at the given line number, then it constructs the TestClass::test_method identifier that the command line test runner expects.

Rather than invoking testit directly, I have a NeoVim keystroke that grabs the current filename and line number and submits a testit command in a separate Tmux pane. That makes it easy to trigger tests from my editor, as well as re-run tests without having to find the same place in the editor.

gh-open & gh-update

When a pull request is ready to open, I polish up my local Markdown draft and run gh-open. That parses the YAML frontmatter out of the Markdown, constructs a title, submits the PR via GitHub's API, requests reviewers and adds labels, and opens the PR in my default browser. If the PR needs any screenshots, I edit the description via the browser. I've aliased gh-open to a gh subcommand with gh alias set open '!gh-open $@'.

I also have gh-update, which takes the latest version of the local Markdown file and updates the pull request. If the PR has images, they're be lost; probably I should add a script that copies the current PR description into my local file.

qlink

I use Espanso as a text expander, most often for generating links to PRs and tickets. Those links go in Slack, personal notes, or comments in GitHub and Jira, and depending on context they need different formats. For that I use qlink ("quick link"). qlink takes a small specifier that names the source of the URL and the output format to use. The p. specifier means "get the URL from the clipboard and output a short-form Markdown link". j5555, means "create a long-form Markdown link for Jira TICKET-5555". To generate a long-form link, the script fetches the title from the appropriate API.

Here's a poor-man's version to get a long-form Markdown link from the URL of a pull request:

gh pr view <URL> \
  --json title,url,headRepository,number \
  --jq '"[\(.headRepository.name) #\(.number) - \(.title)](\(.url))"'

gh-pr-list

This script I trigger from Alfred. I have a workflow that runs it for a handful of different keywords, one for each repo I work in. Besides taking the repo name, the script takes a shorthand search query, constructs a URL for a GitHub pull request or list of pull requests, then opens the URL in my browser. The supported shorthands are:

• no query: open the list of all PRs in the repo
• digits: open the PR with the given number
• starts with #: search for PRs with the given label
• alphanumeric characters: search for PRs by the given author

grase

I prefer rebasing my branches to merging in the mainline branch. Rebasing keeps my commits together, and only rarely have teammates complained about the change in branch reference. I always use interactive rebasing so I can verify what commits will be moved. Originally grase was a Bash alias for git rebase -i <mainline-branch>, but since .workspace.yaml captures the target branch, grase is now a script that reads the .workspace.yaml field and rebases on the correct branch. This is especially useful when I have stacked PRs, where changing one branch requires rebasing downstream branches.

grase is an example of how these automation scripts feed off each other. The .workspace.yaml file I originally created for wso has useful information for other scripts.

checkin

These scripts cross repo boundaries, so none of them live in any of the projects I use them for. Instead I keep them in a few external repos (plus some private repos). After tweaking things here and there through the day, it's tough to remember what changed where, so checkin reads directory paths from a CHECKIN_PATHS env var, then goes through the directories one by one, spawning a subshell in the given directory. Then I stage code in the Git index. When I'm done, I exit the subshell with Ctrl-D, and checkin commits the changes with a generic message and pushes to the remote repository.

Running checkin is an easy routine to follow at the end of the day, and it reminds me of some fun I had.

The script takes an optional argument to read from a different environment variable, allowing me to check in specific groups of repos. checkin I run daily; checkin weekly I run on Friday to capture changes in less frequently touched repos.

If you have scripts you use to automate your workflow or make it more fun, I'd be happy to hear about them.

git-fixup

I make a lot of small, frequent commits, checking in every time the code works and has a meaningful change I wouldn't want to lose. Then, if new work gets the code in a tangle or breaks something I don't understand, I can clear the mess by resetting the working directory to latest commit. Tiny and always-working commits also helps git bisect.

Occasionally commits need amending. Some commit in a long list of commits broke a feature or introduced a bug that didn't get noticed. Rather than just add the fix to that long list, I prefer to update the commit that introduced the problem. To do that, I add a commit whose message starts with "fixup", then do an interactive rebase, which allows re-ordering commits and indicating that the fixup commit should be squashed into the commit before it. Then the original commit is cleaner.

While branches are often short-lived enough to rebase the whole branch, it's tricker to rebase when developing directly off the main trunk. One has to find the commit hash for the commit that needs to be amended then run git rebase -i <hash>^. To turn the process of finding a commit hash and rebasing into one step, I use this script:

git log --oneline -50 \
    | fzf \
    | cut -d' ' -f1 \
    | xargs -I {} git rebase -i {}^

That lists the last 50 commits with their short-form SHA and commit message, and pipes them into fzf where you can search for the commit message of the commit you want to rebase onto. Select a commit by moving up and down and/or searching and hitting Enter. Then git rebase -i <hash>^ will run with the commit you selected, which opens your default text editor where you can move the fixup commit to where it belongs in the list, mark it with an f for "fixup", then exit and apply the rebase.

git-regress

When reviewing code that includes tests, I run the tests on my local machine to surface any missing environment variables, potential OS incompatibilities, test flakiness, and sometimes even tests that aren't picked up by the test runner.

I also want to see that the tests can fail. Sometimes the tests run but the assertions are broken, such as the case of the .assertTrue that forgot the () after it, preventing the assertion from actually being invoked. The easiest way to see new tests fail is to undo the application changes the tests are checking.

To undo a branch's logical changes but not its tests, use git diff <some-branch>... -R -- <directories> | patch -p1. That creates a reverse diff of specific files, then applies the changes.

To simplify finding the code to undo then patching, I use this script that gives fzf all the changed files on a branch, which lets me select the files to revert then applies the reverse diff of those files:

mainBranch=$(git remote show origin | grep 'HEAD branch' | cut -d' ' -f5)
toRevert=$(git diff $mainBranch... --name-only \
  | sort -u \
  | fzf --ansi \
      --disabled \
      --bind 'j:down,k:up,q:abort' \
      --preview="git diff $mainBranch... -- {}" \
      --preview-window=right:60%)

if [ -z "$toRevert" ]; then
  echo "No directories or files selected."
  exit 1
fi

git diff $mainBranch... -R -- $toRevert | patch -p1

You may want to add a step after git diff ... that takes the files changed on the branch and includes their parent directories, so you can revert the changes in a whole directory without having to select every file under it.

If you have suggestions for improvements to either of these scripts, or if you have your own scripts that help with your workflow, please email me.

The little guy is a born manager. My friend Joe has a term for that kind of response from a leader. Years ago I was pulled off a project to work on a more urgent project, and during it I wrote some convoluted code that I should have refactored before publishing. When a reviewer called me out, I complained about the rush. The next morning, the project manager left a comment: "You’ve been doing a lot of awesome work Eric! Your contributions, insights, and suggestions have really helped the [project] effort. Thanks!" When I told Joe that story, he called it "affirmation bombing".

Leaders often address complaints with compliments. But when praise is just a tactic used to assuage frustration, it comes across as disingenuous. Worse, it can to backfire if the receiver sees through such praise and interprets it as, "Your negative emotions have given me negative emotions, so I want them to go away. If this bit of positivity doesn't give you positive emotions, you must either hide your negative emotions or go away yourself." Praise can, counterintuitively, deepen a negative feeling.

To keep my praise authentic, I tend to be sparing with it, but as a dad I've had to learn to be more generous. Kind words still have to be spontaneous, not calculated, so I've chosen to get sensitive to what's worth praising. Trying an unfamiliar food. Keeping a screwdriver in the head of a screw.

I've also learned to give myself some kind words. It's easy for me to discount praise, to see it as motivated, to know it's part of a scheduled review cycle, to wish it was more substantive. But rejecting all praise leads to long, dark moods. It's important to recognize compliments from others even if it's sometimes tactical. Rarely is it outright dishonest. Kindness prompted by a complaint is still kindness.

At one company I worked for, we emailed positive remarks from a client out to the whole staff with a subject line of "Nice words". One day I decided to adopt that practice for myself. Whenever someone gives a kind word, even if it was affirmation bombing, or a perfunctory farewell when changing jobs, or an annual review where the boss instructed everyone to review gently, I write it down. Tim Ferriss does something similar with a "Jar of Awesome". I keep a digital version. Every now and then I come across one I'd forgotten. "You have a nice reading voice." "We should all be using your terminal setup." "You've been a huge inspiration to me." "I love the Eric notes." "What you did is how I want this department to behave." "You're probably my favorite writer." I can quote the project lead's original affirmation bomb word for word because I wrote it down in my nice words file.

Some nice words were offhand comments, and while I may still discount a lot of compliments as general politeness, I do write down the things I find myself thinking about later. Fading memory doesn't mean the emotional boost of kind words also has to fade.

When I was a teenager, my father made me read Sean Covey's The 7 Habits of Highly Effective Teens, which used the metaphor of a relationship bank account: you have to make more deposits than withdrawals, and unlike an actual bank account, in relationships a deposit tends to evaporate and a withdrawal turns to stone. The same happens in our relationships with ourselves. For decades we remember an embarrassing moment, a typo in a tweet, a negative comment on a blog post, but we forget the compliments and nice words. Keeping a jar of awesome or a document of nice words is a way to combat that human weakness. Beyond that, documenting the positive things people say about you shows what others perceive to be your strengths, which can provide insight into how you can be your best self.

Sure there are bad days and low moods, but you are doing a good job!

1. Draw to create focus

It's easy to get distracted during a 40-minute or longer talk, but drawing creates focus by distracting the part of the brain that generates distractions. Doodling occupies the hand and the brain's visual processing. Even abstract patterns can serve as memory anchors, but infusing your doodles with content from the presentation locks it even deeper into memory, and it's more fun.

You don't have to be an artist to make sketchnoting fun or memorable. Simple drawings are great. Elaborate illustrations often detract from focus, rather than enhancing it.

2. There are many ways to be visual

Sketchnotes frequently translate a presentation's visual elements into pictures, but many presentations are mostly text. Notes without a visual language can still be sketchnotes. Just capture text in visually interesting ways: make lists look like lists, underline important works, use an accent color for some words, write some words in ALL CAPS. Wrap sentences and fragments to leave room around them where you can write related concepts.

A presentation is given linearly, one word after another, but the ideas have non-linear relationships that benefit from being captured in two dimensions. Paper allows you to de-linearize the content, even if you don't draw any pictures.

3. Use pen and paper

Using physical pen and paper is freeing. I've sketchnoted on tablets, but switching pens and colors is distracting. If the app allows editing—which most do because of the imprecision of stylus input—then it's tempting to clean up a drawing instead of listening. Paper has no distracting notifications or apps, and the battery never dies. You might not be able to erase, but mistakes can be memorable too.

I take sketchnotes on an 8"x5" index card that's blank on both sides. For pens I use basic utensils: a Pilot V5 and an orange felt-tip Paper Mate. Both provide smooth lines. The one fancier tool I use is a Copic N4 marker with a brush tip, to add some color or shadow to drawings, though when it's used up I'll probably look for a lighter shade of gray.

4. Sketchnote for yourself, not others

Sketchnotes are never detailed enough to reconstruct a talk, so they tend to have little meaning to those outside the audience. Even for those who did hear the presentation, your personal notations are likely to be opaque. You might share your sketchnotes with the speaker or other members of the audience, but don't expect anyone to use them as a reference. They're for you. The act of making them is the valuable part. Your memory of the event will be embedded in your own physical movements of drawing and writing. Share your notes in recognition of the time and energy the speaker put into their talk, and as a token of the time the audience spent together, but no one will get more out of your notes than you do.

5. Do it!

You can start sketchnoting without experience, without tips, and without a grand reason. Do it for fun! Do it to enhance your memory of the occasion. Do it to create connection with others.

The purpose of sketchnoting isn't to become a master. You don't need artistic ability or perfect penmanship. The goal is to focus your attention, make you think more deeply about others' ideas, and have and share a memorable experience.

Sketchnoting is a gift to your future self.

(For concrete tips on sketchnoting, see my earlier post and Mike Rohde's The Sketchnote Handbook.)