The value of a field guide
Roger Stringer / February 25, 2017
3 min read
According to Wikipedia:
A field guide is generally designed to be brought into the 'field' or local area where such objects exist to help distinguish between similar objects.
One of the companies I worked at years ago, had an internal knowledge base they called their field guide, it contained everything you needed to know from who to talk to, how to set up VPN and email and group chat to how to get company swag.
Field guides let you navigate your company culture and figure out what you need to figure out.
Before that, I'd worked a few places that kept an internal wiki or knowledge base, but it never got used as the structure was always a mess. But the structure of the field guide, just made so much more sense.
Since then, I've kept one for everywhere I've worked and kept it updated as well.
Field guides don't contain sensitive information like passwords or server access, or any info like that, and they aren't supposed to.
There are other ways to share that information with team mates, such as meldium, lastpass or 1password.
A field guide is meant for sharing company procedures and general knowledge only.
They are meant as a knowledge repository so people can quickly get onboard with a company, or so people can look back anytime they want to find information.
For example, for my work on Flybase, I use a private github repo.
People who work on Flybase with me are invited to join this repo, and they have access to various information such as how things work, why things work, who makes them work, etc.
This field guide also contains resources on how things are built at Flybase, how tutorials are written, how READMEs are written. It's all in there.
Since this field guide is mostly markdown files, I decided not to use the built-in wiki that Github provides, instead I write the markdown files directly into the repo.
The Wiki works fine, and I use it on a lot of repos, but since the field guide can grow pretty big, keeping it in the actual repo itself lets it grow easier
The structure is along these lines:
- README.md (the index file)
- /marketing
- README.md
- file2.md
- /blogging
- README.md
- /coding
- README.md
- /etc
- README.md
- /yada
- README.md
- /more-yada
- README.md
When you click a folder, it automatically loads the README.md file, which acts as an index file, and displays a tree of articles.
Github in itself makes a great knowledge base for storing information, so why not make use of it?
I also keep a field guide as a private repo for myself, where I keep track of stuff such as projects, interesting articles I want to look back on later, sometimes even drafts of posts I want to write down the road.
Create one however you want, and keep it updated with interesting reading and you'll see what I mean.