DEV Community: Tom Hall

Beyond Taking Notes (or how I joined the #roamcult)

Tom Hall — Sat, 15 Feb 2020 03:48:42 +0000

I’ve always bristled at the term ‘self-taught’ to describe myself because a) it sounds terribly pretentious and b) it’s simply inaccurate. I don't have much formal education (less than one semester of high school and some college) but I didn’t build a decades-long career in technology by conjuring knowledge out of thin air. I’ve learned from reading countless books, articles and blog posts, watching endless videos and having long conversations with a lot of people a lot smarter and more knowledgeable than me over many years. In other words I’ve had many teachers and even more lessons, just rarely confined to an uncomfortable chair in a cold, concrete building.

The downside to all of this is despite craving continuous learning, I never really learned how to learn efficiently. I’m endlessly curious and my reading comprehension has always been high, but without ever having learned how to learn I end up retaining very little of what I consume, and even less (it seems) as I get older. As an example I have earned numerous technical certifications during my career in technology, but in each case my method was something like:

read the study guide cover to cover
try to memorize as much as possible
take the test soon after
if I failed (as happened maybe 25% of the time) then repeat the cycle. (I had to do three rounds of that process for one of the exams in the Novell CNE track back in the day.)

I knew I was supposed to be taking notes and reviewing things and I really did make an effort to do that, but I just didn’t know how. I would end up taking such copious notes that it was as if I were trying to make a copy of the text, or so few notes that all the context was lost and they were useless.

The same goes for things I've taken a personal interest in. For example I’ve always been interested in philosophy (primarily metaphysics and ethics) and have spent years participating in lengthy discussions and debates with people from all walks of life (mostly in online forums) about religion, culture, politics, psychology, etc. I’ve also taken some college courses and read a lot of source material on those topics over the years.

All of this has helped me form a worldview that I am comfortable with--and even to have a higher tolerance for those whose conclusions are different than mine--but vast swathes of the information and reasoning that helped form who I am today are simply lost to me. Granted a lot of those discussions still persist in text on various websites, but it would be nigh impossible for me to go back and recreate the paths I took along many different threads to reach the conclusions that I eventually reached.

Maker Mind

Until very recently it never occurred to me that others might have similar struggles, much less have discovered strategies for overcoming these inherent limitations. My first real step toward this realization was when I discovered and subscribed to the Maker Mind newsletter by Anne-Laure Le Cunff.

With articles such as Learning how to Learn and How to Read a Book, I was instantly drawn to subscribe. So it is that a couple weeks ago I read her article How to use Roam Research: a tool for metacognition and began a whirlwind ride down the rabbit hole of knowledge management and productivity research.

If that lead-in wasn’t warning enough, let me make it more explicit:

This stuff is all very new to me. I am not an expert in any of the techniques or tools I’m going to talk about here and I am very open to corrections!

I just learned about all of this stuff in the past couple of weeks, so please check out the blogs, books, and videos referenced here and come to your own conclusions about whether I’m representing these ideas adequately. I only hope to spark some interest in these methods and tools while not getting anything horribly wrong.

Roam Research

The first thing I did after reading Anne-Laure’s Roam overview was to create an account at https://roamresearch.com and check it out. My honest first impression: I had no idea where to start. The tool is brilliant, the documentation is not yet great. There are scattered help docs and videos about various features and such, but no step-by-step getting started guide. There are understandable reasons for this, such as: a) there are only currently 2 full-time engineers building the product, and b) there are many different use cases for the tool, so any “getting started” guide would have to be opinionated (and therefore potentially limiting).

Fortunately I soon found another Maker Mind article called A beginner’s guide to Roam Research: getting started in 5 easy steps and that was exactly what I needed to start getting my toes wet in Roam myself. As I started to get more familiar with how Roam works I simultaneously started digging into what inspired its creation, how it differs from other tools and other examples of how and why people are using it.

What would I use Roam for?

Building a Second Brain

Early on I stumbled on a YouTube video of an interview with the creator of Roam, Conor White-Sullivan, by someone named Tiago Forte. Tiago wanted to talk to Conor about how Roam might benefit people who sign up for Tiago’s Building a Second Brain (BASB) course.

Tiago’s BASB overview could have been addressed directly to me:

“How many brilliant ideas have you had and forgotten? How many insights have you failed to take action on? How much useful advice have you slowly forgotten as the years have passed?

We feel a constant pressure to be learning, improving ourselves, and making progress. We spend countless hours every year reading, listening, and watching informational content. And yet, where has all that valuable knowledge gone?"

I haven't taken Tiago's course but I'm really interested in it. Moreso if he introduces a cohort built around the use of Roam Research instead of Evernote. I have nothing against Evernote--I've used it off and on for years--it's just that paradigm never captured my imagination the way Roam has.

Zettelkasten via “How to Take Smart Notes”

During the aforementioned interview Conor and Tiago discussed their shared admiration of a book by Sonke Arens called How to Take Smart Notes, which I picked up a few days ago. This book is essentially a modern introduction to a system of note-taking used to great effect by Niklas Luhmann, a German sociologist in the middle of the 20th century called Zettelkasten which is another super interesting rabbit hole to go down if you’re so inclined. A good overview of the book is How to Take Smart Notes: A Step-by-Step Guide by Nat Eliason. While you’re there his post Roam: Why I Love It and How I Use It is worth reading as well.

Bullet Journal

I initially found it odd that the default format of the Daily Notes pages is a bulleted list, but as I started to use it for my daily journaling I realized it was very comfortable for me. I hop around from topic to topic a lot when I’m writing so it’s just a natural fit to have one thought per bullet. I also learned that this was inspired in part by bullet journaling, which is a really interesting method for increasing productivity. An overview is here: How to Bullet Journal

All these things and more are made much easier with Roam Research. Check it out yourself!

Roam Resources

RoamResearch public Slack team
How to Use Roam to Outline a New Article in Under 20 Minutes
Shu Omi has some helpful videos on his YouTube channel.
Follow #roamcult and @roamresearch on Twitter
Official subreddit of the roamcult https://www.reddit.com/r/RoamResearch/)
Metaroam - A Roam Database about Roam

What is a "DevOps Engineer"?

Tom Hall — Mon, 04 Nov 2019 18:38:36 +0000

Whether you're reading this because you heard that DevOps¹ Engineer is among the highest demand, best paying jobs in tech so you want to learn more about how to get into the field, or you are a DevOps Engineer (by title) but aren't sure what that's supposed to mean, this article is for you.

The bad news is that there is no universally accepted answer to the question "What is a DevOps Engineer?". The good news is that this ambiguity makes it a lot easier for people with very diverse skill sets to become DevOps Engineers and for people who work as DevOps Engineers to forge their own path (to an extent).

Who am I?

I've been working in IT for 20+ years²; as some variant of DevOps Engineer in five separate companies over the past six years. I'm very active in the DevOps community and have done extensive reading on the topic of agile, lean and DevOps. I've attended 10+ DevOpsDays conferences (Austin, Atlanta, Chicago, Dallas, Detroit) since 2014, and I'm on the organizing team for DoD Austin.

What even is DevOps?

It's easy to understand why a lot of people dismiss DevOps as a meaningless buzzword. It was coined to express a simple idea--bringing 'dev' and 'ops' together--yet most definitions out there today are at best context-dependent interpretations and at worst attempts to convince you that "doing DevOps" requires you to buy a specific product or service.

One thing most everyone agrees on is that DevOps requires some level of "transformation" in how your business operates. I'm not going to go into detail about all the things a DevOps transformation involves because that has been done many times before³, but usually it entails changing how your business works.

Ok, so what is a DevOps Engineer?

With as much confusion and disagreement as there is about the meaning of DevOps, it's no surprise that there is a lot of confusion and disagreement about what a DevOps Engineer does or what skills are required to do the job. I don't even like the job title because I think it reinforces misunderstandings.

Based on my own experience reading job descriptions of, interviewing for, and having the title DevOps Engineer in five very different organizations, I can say with a high degree of confidence that there is no consistent definition.

The most important thing you can do when interviewing for a DevOps Engineer role is get clarity on exactly what you will be expected to do.

So, what might a DevOps Engineer do?

(If this seems like a ridiculously broad list of technical specialties that no individual could reasonably be expected to have mastery of, that's because it is.)

Release Engineering

Manage CI/CD tooling
Document current build/deploy process
Standardize build/deploy process across apps
Optimize build/deploy process across apps

Infrastructure Engineering

Design/Administrate cloud infrastructure
Document current infrastructure topology
Create and maintain provisioning code

Reliability Engineering

Standardize metric reporting and log aggregation
Configure performance monitoring, reporting and alerting
Production support and incident management
Document performance standards and audit guidelines

System Administration

Internal tools audit, selection, management
User ID and access management
System audits and patching
Security audits and issue remediation
Design and enforce security standards

DevOps Advocacy

Being a DevOps 'champion' in the organization
Leading training sessions on DevOps principles
Creating and/or running a DevOps 'Dojo'

Say what now?

Yeah, that's a whole lot of stuff that requires many different skill sets. You'd have to be nearly superhuman to have mastery of all those responsibilities. So does that mean you should abandon all hope of becoming a DevOps Engineer? No, not at all. As mentioned before every organization is different and will have different expectations for the DevOps Engineer role.

Many of these practices used to be (and sometimes still are) managed by people with job titles like Release Engineer, Sysadmin, Network Engineer, Build Engineer, etc. The newer term 'Site Reliability Engineer' or 'SRE' is sometimes used in place of DevOps Engineer, but in fact the SRE model is much more prescriptive.⁴

As things are today, if you have strong skills or experience in CI/CD, OR cloud architecture, OR system administration, OR coding, AND you have a strong grasp of Agile and DevOps principles, you have a good shot at being a DevOps Engineer.

There is ongoing debate about the "proper" capitalization of 'DevOps'. My preference is for Pascal case to emphasize that the word is a portmanteau of Development and Operations, not a new practice area. ↩
Before transitioning into the world of software development via DevOps, I worked as a Novell CNA/CNE on various contracts throughout the mid to late 90's and managed the infrastructure for Dell's Enterprise Server/Storage/Virtualization training for nearly 8 years in the mid 00's. ↩
Some essential reads are Accelerate, by Nicole Forsgren, Jez Humble and Gene Kim, The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford and Team Topologies, by Matthew Skelton and Manuel Pais. ↩
I recommend this YouTube video for a nice explanation of the relationship between DevOps and SRE. ↩