Cody Bunch has been discussing note taking on twitter recently and has started a grand experiment today. I believe that Cody wants to dive into all the potential uses of note taking throughout our workdays and is soliciting feedback. I can’t speak to the entirety of taking notes as an IT person, but I’d like to share some information about my work “diary”.

I do keep a journal for work. No, I don’t write “Dear Diary” at the top of every page, but I do write in my journal every day so I jokingly call it my diary. As you may have guessed from the word “write”, it happens to be a paper and pen journal. I keep things short and to the point, so an 8 hour day rarely takes more than half a page in a college ruled notebook. It’s not meant to be exhaustive, but to capture the essence of a day or an outage – most of the details would be in a ticket number I reference. I also note when I’m working on a weekend and when I take vacation. For instance, my journal around Thanskgiving will look something like this:

11/25/2015

Processed a bunch of account creations, apparently everyone really wants to work on the holidays!

At lunchtime, $customerX blew up. $SiteY required an RMA of their $widget. Their building got hit by lightning last night and apparently our equipment wasn’t the only thing affected. Hope nothing else dies from this. Ticket 123456789

Watched a video about $technologyZ. Pretty awesome that you can foo the bar with it! Looking forward to some lab time with it next week, but first: TURKEY

11/26/2015 – Thanksgiving, holiday, TURKEY NOM NOMS

11/27/205 – holiday

Someone didn’t get their account request in on Wednesday so I got called at 7am to take care of it for the holiday crew. Boo.

A customer’s building got struck by lightning, which might be important if another piece of equipment dies next week. My holiday and vacation time is recorded so I can put those in the time system or use it as evidence if I get audited. I wrote up when I got an “on-call” engagement; this may be useful if I find myself getting called too many times for documented tasks. I can pull these events and ask my manager why I’m getting woken up in the wee hours constantly for things that shouldn’t require me. Whatever it is that happens, I’ve got it recorded along with tickets numbers that provide more precise details. I also keep it light and humorous, it’s for myself – but I write as if other people may see it. No slandering coworkers or customers.

I have been doing this a while. I have work journals going back to 1997. I can look up that time we had a freak tornado in Pittsburgh, PA, our building got struck by lightning, and 70% of our hubs were blown out because of a lack of surge protection (spoiler: tornados suck). I can also look up the last 6 months of issues for a customer and tell my boss whether they’re having more or less outages over time. That’s really useful, especially for some of the seemingly unconnected-at-the-time events that later prove to be connected, or systems that are difficult to search or correlate information in. But that’s not the real reason I keep a journal, just a bonus.

The real reason I write in my diary every day is that the act of writing a note to myself, with a pencil on a piece of paper, reinforces the memory I am describing. Most days, I couldn’t tell you what I ate for lunch the day before. But I can tell you that I held a meeting with a customer and found a solution to their problem, because I lived it, I wrote it down, and then I read it back to myself and remembered it again. I’ve tried electronic diaries and I don’t have the same success in recalling previous memories. The tactile sensation of the paper and the pen, where I place the words on the page – even the misspellings that I scratch out and rewrite correctly next to the original – and reading the entry back to myself; these sensations and actions help me move the memories of the day from short-term to long-term memory and recall them more easily. In most instances, I don’t actually need to refer to the journal, because now the memory is already accessible! There’s even science that shows how recall from words on paper is generally higher.

If you find yourself with a poor memory of your work week, or just need a little more precision in your memories, try keeping a work diary on pen and paper. You may find that a few weeks of a diary helps out. This may not work for everyone, though. If you have other tips for keeping a diary or note taking in general, drop them in the comments!

I was looking at the puppet module zack/r10k’s github repo the other day and I noticed these fancy shields all over it. They include the version and number of downloads from the Puppet Forge and a label that says build | passing. This comes from Travis CI. By adding the shield syntax to your repository’s README.md file, you can have this shield as well. Here’s the syntax, substitute your github user and repo names where appropriate (unless you want to display the build status of my certs module for some reason) and use travis-ci.com for private repos:

[![Build Status](https://travis-ci.org/rnelson0/puppet-certs.png?branch=master)](https://travis-ci.org/rnelson0/puppet-certs)

You should add this in a new branch, of course, along with any other shields you want to use. There are plenty available at Shields.io! Before you create a PR, however, there are two other changes you need to make. First, an edit to your .travis.yml:

branches:
  only:
    - master

This tells Travis CI to only perform builds against the master branch. You can add additional branches if you want, of course, and you’d change your shield’s ?branch=master text to the other branch name. The next step is to change your Travis CI settings for the repo:

Build pull requests was probably already enabled, so that when you created a PR Travis CI would test it, but Build pushes may have been disabled. With Build pushes enabled and the only setting of master, any push to the master branch – which includes merging a PR into the master branch – will kick off a Travis CI build. You can now go ahead and create your PR and merge your changes. The shield will initially say unknown for the status. If you look in Travis CI, you’ll see a build start for the master branch, and shortly thereafter it will complete. Refresh the view of your repo’s main page or README.md and you should see the shield update to the status of the latest build!

If you did things out of order, like enabling Build pushes after the PR is merged, will still have an unknown status. You can either hold tight until your next PR/merge or do a simple change on master. An easy change is to edit the README.md through github.com and add a blank line at the end. When you hit save, GitHub creates a new commit, which again counts as a push, and therefore Travis CI starts doing a build. Voila!