Open Handbook#

The Joy of Reuse#

Save all your work#

Most students complete their school work, turn it in to their professor, then never think of it again. These efforts then cross the event horizon into the black hole of a computer hard drive, never to emerge again. If this sounds like your standard practice, consider a change now that you’ve arrived at college. When you write something (essays, notes, reports, projects, code), or when you use something (course readings, research, data), keep a copy of it in some organized folder system so you may return to it in the future.

Taking the time to meticulously save all this work may sound counterintuitive—the class is over, right? But that essay you wrote freshman year, the notes you took on a scholarly article, the readings you dutifully annotated in your history class, may be very useful to you in some future project that you can’t anticipate now. Summarily tossing all of your work into the black hole forces you to start over again and again.

While it is important to save your finished work, it is also critical that you save the research, notes, or data that contributed to that project as well. Try, as best you can, to capture all of the inputs that led to your finished work and save them in some organized way. Successful scholars and students return to prior work and research all the time—reshaping, repurposing, and extending prior efforts. They understand that knowledge is cumulative: it accretes and deepens over time, often by building on what came before.

This is the joy of reuse.

Staying organized#

To retain your work and stay organized, you might use a simple paper system made up of manila folders or large 3-ring binders. Or you might use a hierarchical folder system on your computer organized by class, project, or term. Alternatively, you might embrace a powerful bibliographic manager like Zotero or make your own personal knowledge archive with something like Obsidian. Whatever you choose, create a system for staying organized and stick with it.

A poor file-saving strategy#

I assume that most students today will embrace an electronic system to manage their workflows, take notes, and compose texts. Let’s imagine two archive systems to store this typical scholarly work. Here is the first, which I don’t recommend:

/
└── My Documents
    ├── Essay.docx
    ├── hack-dartmouth.py
    ├── ideas.docx
    ├── MyDog_Rex.jpg
    ├── Nosetalgia.mp3
    ├── Notes2.doc
    ├── Notes.doc
    ├── Revision.docx
    └── syllabus.pdf

#

The strategy represented here breaks down very quickly for two reasons. First, after a few weeks of accumulating notes, readings, research, and other important documents, a system with no hierarchically organized folders becomes a confusing and unhelpful jumble. Secondly, the choices for naming the files actively resist discovery and recognition. What, for example, is the subject of Notes.docx? What class was it from? What lecture? Of the many essays you wrote last term, which one is Essay.docx? And Revision.docx is a revision of what, precisely? A year from now you won’t remember, but you may very well care at that time. Unfortunately, the folder into which you’ve dumped these files will have swollen to a debilitating size that will disrupt any attempt to make use of your hard work.

A better file-saving strategy#

Instead of this haphazard and unhelpful approach, each time you place an artifact in your archive, think about your future self who will want to find something quickly, with minimal effort. An important first step in this process is to adopt some kind of logical foldering structure that quickly reduces the effort of finding a particular item. You should make considered and thoughtful decisions about your archive’s structure. Perhaps you will choose to organize your work by year, or term, or class, or project. There are pluses and minuses to any organizational schema, but changing things up later is difficult, so choose wisely.

Perhaps the most critical step in the construction of your scholarly archive is to adopt a strict naming convention for your folders and files. Keep in mind sociologist Kieran Healy’s helpful advice that a “file or folder should always be able to tell you what it is” (7) without actually having to open it. Taking this sound advice to heart, we might revise the previous filing strategy like this:

/
└── My Documents
    ├── Courses
    │   ├── CS1-F20
    │   │   └── hack-dartmouth.py
    │   └── Writing2-F20
    │       ├── essay1-draft01-090720.docx
    │       ├── essay1-draft02-091520.docx
    │       ├── notes-Freire-110520.docx
    │       ├── notes-Percy-102820.docx
    │       ├── workshop2-draft1-101720.docx
    │       └── WR23-syllabus.pdf
    ├── Music
    │   └── Pusha-T-Nosetalgia.mp3
    └── Photos
        └── 2018-MyDogRex.jpg

#

Your system will obviously become far more complex than the simplified example presented above. You might, for example, want to create subfolders within a class to further organize your files. Or you might elect to organize your folders by year and term. Whatever you decide, the key features of a good filing system are detectable here: 1) there is a logical structure to the organization, using course names and file types to determine the names of the folders and 2) the naming convention for the folders and files tell you exactly what they are without having to open them. There is no right or wrong way to make a filing system, and one size will not fit all. You will have to determine for yourself what system makes sense.

File & Folder Naming Advice#

A one-page reference for keeping an archive tidy. The core idea: a file or folder should tell you what it is without being opened, and it should sort itself into a useful order.

The grammar — fixed rules that never change, whatever you’re naming#

Choosing the elements — this scales to the collection#

Include only what you need to tell files apart, and put the thing you’ll sort or scan by first.

Date & separator formats — all valid, pick one and hold it#

Folder-level tips#

“Bryan” refers to Jenny Bryan’s talk “Naming Things,” the widely cited source for the machine-readable / human-readable / plays-well-with-default-ordering framing.

Back up all your data#

All of this hard work of organizing will be for nothing, however, if you don’t take pains to back up your data. Please, I beg of you, back up all your data regularly and keep a copy separate from your main working computer. There are heartbreaking stories of people losing years of work in a hard drive failure, theft, or house fire/flood. Very few people are disciplined enough to back up their work regularly on their own initiative; instead, you should embrace some kind of regular, automated system to ensure your work will survive any tragedy.

A simple, durable rule of thumb is the 3-2-1 rule: keep 3 copies of anything you care about, on 2 different kinds of storage, with at least 1 copy kept offsite (or in the cloud). If your laptop, an external drive, and a cloud service all fail at once we are probably in an end-of-the-world type situation where your essay draft really no longer matters.

One crucial caveat: cloud sync is not the same as a backup. Services like Dropbox, Google Drive, and OneDrive faithfully save whatever you do to every device—including your mistakes. So if you delete a file or a corrupted version overwrites a good one, sync dutifully spreads that change everywhere. What actually saves you is versioning or a true backup system—macOS Time Machine, a service like Backblaze, GitHub, or your cloud provider’s file-version history—that lets you roll back to an earlier state. Turn version history on, and know how to use it before you need it.

At some point in the future you will boot up your laptop and it will begin smoking, or be infected by ransomware, or display the BSoD. You will have no backups. As you cry salty tears you will remember reading these words and not doing anything about it. I told you so.

If you don’t plan to work with huge file systems or lots of data, you may stop reading now.

Very large filing systems#

Most students will find the simple filing system described above adequate for their needs. But if you have an expectation of a very large file system, or if you plan to share a file system with other researchers, you should consider a slightly different approach. Large collections of files are quite difficult to manage; this is especially true when additional researchers are involved with saving and editing files in the shared directory. Special care in the naming of files and folders is critical here to avoid confusion and lost data.

• While each project is different and will require its own approach, there are two best practices that should be followed in any shared research repository: 1) a plaintext README file in each project directory and 2) a shared naming convention for files and folders, described below.

Using README files for large filing systems#

A README file is simply a plaintext file that contains general information about a project. It functions like a roadmap that helps other researchers orient themselves to a new project and coordinate their efforts more easily. Information in a README might include some of the following:

• A short overview of the project.

• The names and contact information of the researchers.

• An inventory list of all the data or documents within a directory (with a short description of what they are).

• If the project involves software: a description of installation, dependencies, how to report bugs, licensing, etc.

• Descriptions of file versions, if they are revised in some way.

• If there are multiple subfolders (as in the example below), those folder paths should be clearly indicated to show their location and contents.

• A dated list of updates to the project as they occur.

• Suggested naming conventions for files and subfolders.

• Descriptions of how other interested researchers can join you and your work.

• Descriptions of possible avenues for future work with the data or project.

Example README file#

#

#

A very large file system example#

/
├── Project-Alpha
│   ├── Data
│   │   ├── 20190702-WebScraper.py
│   │   ├── 20191012-DataDump01Analysis.docx
│   │   ├── 20191013-DataDump01.xls
│   │   ├── 20191015-DataDump02.xls
│   │   ├── 20191102-Visualization.rdata
│   │   ├── 20191104-VisualizationV01.rdata
│   │   └── ...
│   ├── Docs
│   │   ├── 20190819-ProcedureManual.docx
│   │   ├── 20191113-PublicTalkPresentation.pptxt
│   │   └── ...
│   └── README.md
└── Project-Beta

#