Organize a Project You Can Find Again

Paths get easier to remember when the tree reflects the work inside it. That does not take an elaborate system, which nobody maintains past the second week anyway. It takes three things: a clear project boundary, names you will still recognize later, and a predictable place for each kind of file.

Here are the field-notes files arriving the way files actually arrive, loose in Documents:

report.py
observations.csv
monday.txt
project notes.txt
outline.txt

And here they are given somewhere to live:

field-notes/
├── README.txt
├── report.py
├── data/
│   ├── observations.csv
│   └── raw/
│       └── monday.txt
├── notes/
│   └── project notes.txt
└── drafts/
    └── outline.txt

The project directory (field-notes) acts as a container that you can move, copy, or back up as one thing. data holds inputs, notes holds explanation, drafts says “unfinished” without anyone having to remember. README.txt explains the layout to whoever opens this next, which is usually you, having forgotten everything after a few weeks.

Names that travel well

Modern systems accept almost anything, spaces included. project notes.txt is a perfectly legal filename. In a shell it needs quoting, or that space makes one name look like two. This is something we will practice in the next chapter.

For anything that might move between tools or operating systems, a conservative file name saves grief:

• use meaningful words, not stuff or new folder;

• use letters, digits, hyphens, and underscores if it helps;

• use an extension that makes clear what the file is;

• write dates as 2026-08-12, from the largest unit to the smallest, so they sort by name.

A name like final-final-2.txt tells you nothing about what the file holds or which copy to trust. observations-2026-08-12.csv tells you both. When versions genuinely matter, a version control system like Git does this properly, but that is a different course.

Build a disposable project

Time to make something real. You will use this directory again in later chapters, so it is worth doing now.

Use File Explorer on Windows, Finder on macOS, or your Linux file manager. Work inside your own Documents or home directory, well away from anything important.

1. Create a directory named computer-fundamentals-practice.

2. Inside it, create three directories: data, notes, and archive.

3. Open a plain-text editor: Notepad on Windows, TextEdit on macOS with Format > Make Plain Text, or your Linux desktop’s Text Editor. Plain text stores the characters without word-processor formatting. Type Practice workspace and save it as README.txt inside computer-fundamentals-practice. Check the full filename: it should not end in .rtf or .txt.txt.

4. Use the file manager’s location or properties view to find the complete path to README.txt.

5. Write down both that absolute path and the relative path from computer-fundamentals-practice.

You are aiming for this, with your own home path above it:

computer-fundamentals-practice/
├── README.txt
├── archive/
├── data/
└── notes/

Relative path from the project directory: README.txt

Your absolute path will look something like C:\Users\Sam\Documents\computer-fundamentals-practice\README.txt on Windows, /Users/sam/Documents/... on macOS, or /home/sam/Documents/... on Linux. Your drive, username, and starting directory will differ, and that is the point of writing yours down rather than copying one.

Before you call it done: open README.txt from inside the project and check it says Practice workspace. If it is not where you expected, walk back up the parent directories one at a time. If you somehow made two copies, compare their absolute paths before deleting either one, because the path is the only thing that tells them apart.

You now have a disposable place to work and an exact route back to it. Next chapter: why anyone would type an instruction when there is a perfectly good window full of icons right there.