Cody Bunch Some Random IT Guy - OpenStack, DevOps, Cloud, Things

Note Taking as a Professional Practice Part 2 - Should you take notes?

Other tentative titles were “Why Take Notes” but hell if I’ll be seen asking why. Why why is a terribad question however, is the topic for another time.

So: Should you take notes?

The Case Against Notes

I don’t take notes.

Well, more correctly, like dieting, I don’t do it as often or as consistently as I should. There are a number of reasons:

  • Most anything I’d take notes on, ends up in a blog post, like this one.
  • I’m lazy
  • Also disorganized
  • My handwriting is crap. No really

Crap Hand Writing Exhibit one

Now, computer notes can help with a few of these things, and there have been large amounts of money spent on products to help you do just that. Things like remember the milk for tasks to Evernote and OneNote to any number of cloud back apps from the hipsteresque notebook companies, say mosaic from Baron Fig and the like.

Thing is, unless the practice is deliberate and consistent, it won’t become a habit. If it isn’t a habit, you can’t much gain the benefits. Further, as you dig in, there is some research that hints it’s may or may not be the note taking at all that does it. Rather, remembering what was happening while you were learning the bit of information, the music, how warm it was, the smell, your brain may be able to use that association to help recall. If that’s the case, well, should I take notes?

Some anecdotal links against notes:

The Case for Notes

The flip side of not taking notes, therefore, is taking notes. Note taking, and it’s various iterations, techniques, practices, and the like, have been explored extensively. That is, regardless of medium, there is some benefit to recall when taking notes. Be it for learning a new topic, making a task list, or logging some manner of data or design.

One learned how to take notes in school, practiced it, and depending on the teacher(s), you were graded on it too. That is, graded on your English class notes, and then again on the other format the Science teacher required. Then, of course there were engineering and higher math classes, etc etc.

The benefits of note taking have been studied, at length. I recommend the one on Juror note taking if you have a mild to sever case of insomnia.

Early in my IT career, I moved between a few styles of note taking. The first on something akin to book 1 in the earlier picture. That is, it was lined, had a sewn binding, and some signature counter signature blocks. I wasn’t doing much with said signature blocks, apparently they were a hold over from accounting. These books held task lists, customer details and other tidbits to get back to.

From there I moved into some flavor of Google Desktop searchable text files. These were great, as all I had to recall was a tiny bit, and my notes file, and with luck, solution would come up.

In turn, that sort of gave birth to’s early days. Field notes from the guy fixing ESX (it was still ESX then), when it blew up.

My anecdotal benefits abounded. When I was in the habit of note taking, recall was a bit easier.

Now some links FOR:


Well, here we are at the end of another long post. As my clock ticks past midnight, I’ve only discovered how much I don’t know about note taking. Therefore, I’ll leave you with what you’re likely expecting, do what works best for you. If like me, you find job or learning specific recall fading as you get older, or overburdened with other stimuli, give note taking a shot.

Chromic Disease Journal Template

While I want this to be another long rambling post, I’m not sure that’s not well suited this time around.

Disclaimer: This one goes a bit sideways from the usual #vSensei, or technical posts. However, I do a thing here, that I think might be useful to others, so… well that’s it.

When it comes to Multiple Sclerosis, or other chronic disorders, having a conversation with your doctor can be odd. IF you go monthly, quarterly, or every 6 months, remembering how you have faired, what things happened, and so forth, can be difficult. At least, it is for us. That is, I can’t remember what I had for breakfast today unless I write it down (even then, not really).

Given that, as the MS is back, keeping a journal or log of some sort is starting to be an important part of things for a number of reasons:

  • It lets us communicate more effectively with all the doctors.
  • It provides a quasi objective way to track if things are better or worse over time.
  • Recording non-quantifiable info: What “good thing”™ happened today, how you felt, etc, can help when and if the brain fog sets in.

The template is kept here. It’s a simple markdown file. My process is to copy it each time, date stamp it, add the relevant info, and save it.

It is lovingly adapted from The Wahls Diary, “The Wahls Protocol” pg. 80

Note Taking as a Professional Practice, Part 1 - Down the Rabbit Hole


One thing I have been watching over my time in IT, is the habits of those at the top of their game. At the very least, those who seem to know or do as much or more. The idea here, like watching game footage is for football players, and race footage is for drivers, by studying how others work, we might learn something useful.

This sort of thing, while being good for click through, is also interesting on a number of levels. That is, you can answer some of the “How do they find time for $x” or “How does $x know so much $y”. There are some traps here, say comparing ones own life film to someone elses highlight reel (The FOMO / Facebook depression issue), if you are careful to avoid this, and rather try a number of things out along the way to see what works for you given your environment and such, a lot can be learned.

Notes - Down The Rabbit Hole

This lead me recently down the path of note taking. That is, early on in my career, I used to take copious notes. Notes during training, notes whilst reading a thing. Notes everywhere. When Google desktop search was still alive and well, I had a plethora of unorganized text files, and would ‘google’ for solutions I had encountered before. This practice was replaced with blogs, and so on.

However, what I am striving to understand, is how, we as a trade, as a practice, use notes (or lack thereof) to enrich and enhance our understanding, recall, and so forth.

The Tentative Agenda

This will be an occasional series of posts, that will cover:

  • Should you take notes?
  • What Makes Notes Work (some cognative science behind recall)
  • Materials
    • Electronic
      • Tools
      • Techniques
      • Security
      • Forensic / Legal concern
    • Pen & Paper
      • Tools
      • Which pen / ink?
      • Paper Layouts
        • Grid
        • Dot
        • Lined
        • Combo?
      • Metadata collection
      • Forensic and legal concerns
  • Techniques
    • Mind Maps
    • Rough Notes
    • Journaling
    • Logging
    • Learning
    • Case / Incident notes
  • Non-Note recall

At least, that is the tentative outline, it will likely evolve as I get further and further down this particular rabbit hole.

Halp, pls?

Ok, so I can’t do this without you. That is, it would be rather one-sided and uninformed if I said I was writing about how we as a trade use note taking, and then not have any feedback about how we do it. Rather than put a feedback form out, that is, I don’t want my questions to guide your answers, I’d rather you reached out to me either via twitter @cody_bunch, or via email, bunchc at professionalvmware dot com. I look forward to hearing from you.

Give Local in Distributed Communities

I was brought up to, when practicable, both buy, and give local. What this meant in reality, was you took the extra cash in your pocket, or maybe the banana out of your grocery bag and handed it to whomever needed it. It meant volunteering as a bingo caller at the local nursing home, and so on.

Having uprooted and moved about eight years ago, that took on the flavor of the new town. That is, buy Texan and work with small businesses whenever possible. The give local part stayed about the same.

However, after a conversation at a sushi dive in Tokyo over the recent OpenStack summit, I was reminded, that the most valuable thing we can give is our time. As noted in the post on Finding Time, you can see why time is super valuable. You have a finite amount, you can’t save it for future use, etc etc.

Now, there are ways to give local with your time and tie that to your skill-set. Volunteer for youth hack-a-thons, and for the First Lego League at your local high school, and then some. However, for a lot of us tied up in this ‘social’ bit online, in this multitude of overlapping internet communities, what does that mean?

Locality Whilst Online

Local takes on a different meaning when you are attached to a wonderfully rich, vibrant, and distributed set of individuals. There are a number of ways you can conceptualize locality in this context. One can take a Social Network Analysis approach to things, and discover which areas you are most closely connected to. However, other than an educational exercise, you can likely intuit what resources you use most often, be it, stackoverflow, the VMware forums, Twitter, or something else entirely.

These communities, and more specifically those whom you find yourself interacting with most often, are the beginning of local in this context.

For me, these end up being a number of IRC channels, Twitter, the vBrownBag G+ group, and a few smaller things.

Contributing to Your Communities

Now this is where things get interesting. Each of these communities relies on people to help them run. Some of these folks are employed by the folks who run the community, but by and large, they are volunteer run. That is, a handful of passionate (often one person), burns the midnight oil to ensure things are flowing smoothly. That abuse is kept to a minimum, questions get answered, and in general folks are engaged. At times they go as far as organizing an event or two.

To keep things going that way, reach out and figure out what you can do to help. Send an email to your VMUG leader, find out if they need help finding speakers, sponsors, a venue, and such. Reach out to a podcast you listen to, ask if you can assist. Become a forum moderator. For as many communities as there are online, there are things very well suited to volunteer effort.

A Call to Action

Generally speaking, like everything else in IT, when it’s going well, folks hardly notice. The community keeps running, folks are generally upbeat, engaged, and so forth. However, when something goes awry, say the food at said event wasn’t up to snuff, or the live stream goes blip, etc, well, the reaction of the community can be disheartening, and make one question going on. Out of this comes the call to action:

In this time of year, what with all the calls to give to a charity, donate toys, volunteer time, etc. I’d like to call on you, to volunteer time and effort to those communities you take part in. Be that help moderate the forum, speak at a VMUG, help organize something, whatever. Reach out, give back. Make a difference for that one. That one engineer. That one fledgling admin. That one struggling with something.

Make a Difference

I’ve told this story, in some variant of it, over and over, in a number of contexts. Today I’ve borrowed it from here.

A young girl was walking along a beach upon which thousands of starfish had been washed up during a terrible storm. When she came to each starfish, she would pick it up, and throw it back into the ocean. People watched her with amusement.

She had been doing this for some time when a man approached her and said, “Little girl, why are you doing this? Look at this beach! You can’t save all these starfish. You can’t begin to make a difference!”

The girl seemed crushed, suddenly deflated. But after a few moments, she bent down, picked up another starfish, and hurled it as far as she could into the ocean. Then she looked up at the man and replied, “Well, I made a difference to that one!”

The old man looked at the girl inquisitively and thought about what she had done and said. Inspired, he joined the little girl in throwing starfish back into the sea. Soon others joined, and all the starfish were saved.

— Adapted from The Star Thrower

#vSensei Finding Time

In running the vSensei program, one runs into a number of common themes, which is worth a meta post in and of itself. That is, how did we all find ourselves at this point in our career, with all the same questions, and not much in the way of guidance. I digress.

The common theme that led to this post was in the “But where do you find the time?”. In fact, this was actually a common question before the vSensei program as well. “How do you find time to $x” where $x is write a book, blog frequently, run a podcast, raise kids, etc etc.

There really isn’t a single strategy here, but some general guidelines.

Be Aware

Go to Walgreens, or whatever corner store, and pick up the $0.25 notebook. You know the one, pocket sized, spiral ringed at the top. Yes this needs to be physical. Now, in said notebook, for a week or so, keep track of the things you do. Doesn’t have to be each minute thing, we’re not looking at micro-blogging, rather, a high level task, and then the time you spend on it.

Record this way for a few days, maybe a week or two.

The idea here is to bring a level of awareness and some insight to where you spend your time. In most cases this awareness is all it takes to start finding the time. That is, you’ll look at said list and realize you are spending time in areas that aren’t aligned with where you want to go.

Feed the Right Wolf

Borrowed from The Nanticoke Indian Tribe







This tale actually applies well to a lot of what we work on or towards vSensei wise, however, in this specific instance, the items on the list we created in the “Be Aware” section are the wolves. The time, the feeding. Beginning to see where I’m going with this?

That is, if you want to be a better parent, feed the family time wolf. A VCDX? Feed the wolves that lead down that path.

Learn to Let go

This is another section that is worth of it’s own post. In fact, there have been books written about this. That is, learn to let go of those tasks that aren’t leading you towards your goals. Yes yes, you can’t stop eating to make more time in the day, and there are other say business mandated things you’ll need to do to stay employable. However, you’ll find on your list you spend quite a bit of time on ‘things’ that you may have thought necessary, but in reality, are work spent filling the time. Work spent making the metrics look good, but not really advancing anything.

Buying the Time

The idea here, is to discover which you can fall behind on, even temporarily to buy your progress forward.

The trick with this is, to communicate and negotiate the time and deliverables with those whom are important (family, bosses, etc). To date, each book I’ve published, each event I’ve been to, while they may look great on the twitter feed, have been bought and paid for with time away from the wife and kids. At first I didn’t understand this well, at all. That is:

I came home after a grueling 12 (or something) weeks of various conferences, vmugs, and what not, only to have to announce: “Hey guys I’m off to $city next week.”

To which my eldest replied (in the way only a moody preteen can): “Yeah, whats new.”

At this point, a longer conversation was had about travel, events, and time spent. It’s an area I’m still working on, and likely will never stop working on. I tell the story, so that you understand there is a cost to these things, and the only way to settle said bill, is communication. Communicate with the family, the kids, the boss, and more important than communicate (I feel it’s implied by communicate, however, as it’s commonly used communicate is generally a one way thing), take the feedback to heart and adjust plans accordingly.


If you can get past the wall of words in this post, you’ll have picked up on a way to find time to do the things you’d like to do, and a cautionary tale of what happens when you push a bit too far.

OpenStack Summit Tokyo - Day 2

Today. Today was pretty epic. That is, I spoke to so many folks, all of whom are doing interesting things. Which, I suppose can be said for a lot of cons, but alas, there was a level of depth, meaning, and caring in today’s talks. A level of fluidness as topics moved from tech related things to random other things.

This morning I was joined for a run by a co-racker (co-worker?), and headed off in a different random direction. Towards the end of said run, we passed the Icelandic embassy, and then stopped to pray in a temple that’s been standing since the 15th century. It was nuts.

After said run and some stretching, we did the book-signing thing again: Books!

From there, I spent quite a bit of time on the ‘hallway’ track. Topics and individuals ranged. From Burnout in IT, to new vSensei mentors, an inordinate amount of time trying to understand the habits of the ‘high performers’ in our spheres, to the esoteric details of archival quality forensically sound engineering notebooks, OpenStack Israel, and IPv6 headers that can be adapted for use with Cloud (Service, Tenant, User, and how that can be set as destination headers to help protect the PII in transit), with some time spent planning a major 30-in-30 event, and OpenStack Tokyo, and and and. I’m sitting here 22 hours after I woke up to day, and, well, it doesn’t feel like there is much chance of stopping yet.

Lunch, dinner, all an impressive a blur of amazing conversations. and, with luck, lots of things to come.

OpenStack Summit Tokyo - Day 1

Day number 1, or my second day in Tokyo started a bit early, but, that worked out well, as I managed to get a good feel for the city by taking a quick jog around:

Tokyo 5k Tokyo 5k 2 Tokyo 5k 3

From there, the Summit started in ernest.

Day 1 Keynote

Rather than a live blog or some running notes with commentary, I’ll just call out a few highlights:

Day 1 Book Signing


Book signings I’ve done in the past have lasted 10-15 minutes, and generally ran through a few hundred books in that time. This time we came prepared, with what feels like 500+ books each day of the summit:

So Many

Of course the action shot has me not doing any work:

It begins

The line, it was huge. Hi Mom. For Mom

After this, was a lunch chosen by menu pictures, and a LOT of #vBrownBag sessions.

OpenStack Tokyo Day 0

Tokyo 5k

Hooray! I managed to get from the airport to the hotel without getting lost, and/or dead. That has to be a good thing, right? Once in the hotel, knocked out registration. It was quick and painless, however I imagine today (Tuesday, because temporal things in blog posts can be interesting), it’ll be insane just prior to the keynotes.

As it was late, and I had no desire to have a brownout during book signing today, I had dinner with the #vBrownBag crew at a French restaurant. Yes yes, French food in Tokyo. Today, today local food shall be had.

For the rest of today: Keynote, book signing, #vBrownBag, and lots of sessions.

Tuna Sandwiches

Words of warning. This is one of those long winded rambling posts. There will be good bits here and there (at least that is the hope), but, this doesn't follow good SEO, or copywriting practices. There is no real call to action, no clear intent or message.

On most school days, I’ve taken to walking my now five year old to school. It’s a wonderful way to spend an extra few minutes with each other, and the walk is therapeutic in other ways. That is, its good for all the reasons walks are good: extra exercise, being outside, being mindful / present, and all that. Todays walk was extra special, that is, it triggered this long running train of thoughts on technical debt, and what we leave behind each time we say “Fuck it, Ship it” or we open a firewall port for expedience, cut a corner on an implementation or design due to some arbitrary constraint.

That is, I had this conversation:

Context: The traffic officer / crossing guard was not yet on duty.

5: "Dad, where's that man?"
Me: "Oh, he isn't here yet. Where do you think he is?"
5: "He's at the Tuna Sammich store."
Me: "Tuna Sandwich?"
5: "He went to the Tuna store to get a Tuna Sammich for his butt."
Me: "His butt?"
5: "His Right Butt Cheek. He needs a Tuna Sammich for his right butt cheek."
Me: "..."

You can see how this is sort of therapeutic, a small smile crosses our faces. His at having said butt cheek a few times in a row and gotten away with it. Mine from the innocence, the oddity of it, and most of all, because he said butt cheek. (One can’t be an adult /all/ the time).

It did however, hit me with a pang of guilt. One that is familiar to all parents, I imagine. That is, it was the realization that eventually, he’ll grow up. We won’t walk as much, and while we’ll still talk, it likely won’t have this level of random innocence to it (tho, I’ll be damned if I’m not going to strive for that).

That pang of guilt, by way of a long ass introduction, led me to thinking about what sort of future, what sort of legacy we’ll be leaving to them. I’m not one for thinking too long about the huge parts of legacy, things like the environment or economy and all. Instead, I’m speaking of what sorts of technical legacy we’re leaving around. What the impact is, each time we make a decision, and what that will look like in 10, 15, 20 years time.

Oh, I hear you saying: “No system I build will be online in 15 years.” or “My field expedient Perl code will be re-factored during the next release.”, and lots of other things to the same effect.

These two examples were drawn from my own career. The first one from a middling FiServ (hard to gauge size when small is 5mm and large is multi-trillion). That FiServ was (still is) running an HP MPE/iX system. This system had been stood up when 9GB SCSI drives were amazing. When you were hired on, you heard about how the system came to be, and how much they spent on it, etc. What I didn’t realize at the time, is I was also hearing why it would never change, but that is another story. That system, whilst they’ve added layers and layers of middleware, online services, and the like, is still online, and still has active contracts for 4 hour drive replacement, on 9GB scsi drives.

Think for a minute, at the middling FiServ size, what else might be done, if one weren’t spending a considerable effort maintaining what was ultimately a decision made in haste. One that the presiding admin (architects weren’t really a thing then) decided would be fixed on someone elses watch?

The other example, field expedient Perl, is one that I’ve found almost everyone has an example of in their career. While not 15 years back, I can almost guarantee said code is still running in some class 3 telco switch somewhere. This particular gig, I got from some connections on IRC, it was to work on networking and voice gear for a local telco. Knowing nothing about switching, routing, voice, or really, networking, I figured… why the hell not.

At some point, it came about, that some code my predecessor wrote needed to be updated. Some file format changed or, as the comments in the code I found said: “Some asshat put something in the file they weren’t supposed to”. So, what’d I do? I ghetto patched the crap out of it. To date, if you call one of a few South Florida prefixes, the metadata is routed through that code.

So the point, I suppose to all of this ranting and raving in this post, is pay attention to even the little decisions, and what sorts of impacts they’ll have. Because while we’re doing a decent job on the front end of educating the little IT folks of the future with things like Scratch, RaspberryPi, and all sorts of STEAM groups, 3d printing, etc etc. We’re can do a better job in leaving good systems for them to inherit.

#vSensei Reading List

In working through a few iterations of what I’m now calling the #vSensei mentorship program, a number of common themes have come up. One of those is reading. Lots and lots of it, in fact. What follows here are the most common recommendations reading I give, some general, some not so general.


In here fall books for finding time, getting moving, working on bigger ideas, and the like.

A note on that last one: It is neither self-help, nor management, nor ideas. Rather, a massive tome on tactics and counter tactics used in Guerrilla warfare. It’s huge, uses more formal English, and is awesome for extrapolating ideas out and into your day to day operations, be they startup, or career specific.

One of the common themes encountered as part of the #vSensei program has been that of “I would like to become $x” where $x is some flavor of architect, vcdx, or similar. The books here, aren’t technology specific. Rather, they are to help you open your mind to thinking about how things are designed. This helps for building products to building supportable, rugged infrastructures, that will actually be used:

Quazi Technical

These two both talk process, improvement, and the like. One being much more technical than the other:


This is the start of what should be an ever growing book list.