Digital Bookshelf

created: 2025.10.22. 20:32 · modified: 2025.12.01. 11:01 ·  · license
license

This post was automatically translated and has not yet been reviewed by me. Please read with discretion.

The file explorer will load here. If it doesn't appear after a while, try refreshing the page.

When I was young, I would sometimes see professors being interviewed in clips on TV. Often, I wondered whether the producers really needed to ask a professor for answers like “As the weather gets colder, drink plenty of warm water to prevent respiratory illnesses” on the news, or “Yes, it's true. When the novel <Jaws> was first introduced in Korea, it came out under the title <Agari>” on Sponge. But I suppose they wanted to show not just the answer, but also the credibility lent to it by the professor's position. The bookshelves full of books behind the professors made them seem all the more credible. Looking at those shelves, I vaguely wondered, “Will I have a bookshelf like that when I grow up?”

About twenty years later, I have grown up, but I still don't have a bookshelf like that. A few books and a few stacks of papers I've printed myself are all the materials at my desk in the lab. My sparse workspace isn't just a reflection of how short my research career has been. Even my advisor, who has spent fifteen years at our university, keeps relatively few books on the shelves compared with the professors I used to see on TV.

I think the digitization of materials has played an even bigger part in simplifying our workspaces. Today, we handle most of our materials on computers. As with this very post, I spend far more time reading and writing with a screen and keyboard than with paper and pen. Chances are you do too.

As the amount of material on my drive grew, I needed a system for managing it sustainably. I began developing one around high school, when I got my own computer, and have kept refining it ever since. It has now settled into a fairly stable form.

I imagine nearly everyone who does knowledge work for a living has a system of their own. Yet we rarely get to look inside one another's systems. Physical bookshelves could be cumbersome, but they also offered evidence of our past efforts—the books behind those professors—and chances to learn from someone else's work by accident: “Oh, what's that book?” Digitizing our bookshelves has taken much of that charm away.

So I decided to write a post actively introducing my digital bookshelf. The file explorer at the top lets you explore the actual structure of my archive, and what follows explains some of its more noteworthy parts. Text like this refers to the name or path of a particular directory or file in the archive. ~ is shorthand for my home directory (Macintosh HD/Users/gunheeyi).

Directories

Here are the main directories (folders) that make up my archive.

~/iCloud Drive

With a few exceptions, I store everything in iCloud. I currently use four computers, switching between them depending on where I am and what I'm doing. Cloud storage is essential if I want to work seamlessly across all of them, as well as my tablet and phone. Back when I used a Windows PC and a Galaxy phone, Google Drive served me well. But after moving into the Apple ecosystem, I moved all my materials and photos to iCloud. What I like most is that it is built into the operating system on both desktop and mobile, so it works well without any separate installation.

The first exception to cloud syncing is files downloaded from the web. They go into ~/Downloads. After checking their contents, I move those worth keeping long-term into a directory under iCloud. Otherwise, I delete them immediately or during a periodic cleanup of the Downloads folder.

The other exception is the material in the dev directory, which I'll explain later.

~/iCloud Drive/yearly

yearly is the largest directory in my iCloud Drive. It holds almost everything that can be organized chronologically. As the name suggests, its immediate subdirectories are years such as 2025. Within each year, I sort materials by subject. Under 2024, for example, are 선보엔젤파트너스 (the company I worked for before graduate school), kaist (research and coursework), founders (a student entrepreneurship group I was active in early that year), freelancing (contract development work), and misc (miscellaneous odds and ends). Of course, I could have chosen subjects rather than years as the top-level categories. But thinking in terms of when and then what feels more natural to me. I also like being able to see at a glance what I was or am doing in a given year, so I chose to organize by year.

Sometimes work on one subject crosses into a new year. If it doesn't continue far into that next year, I put everything under the first, primary year. That applies to an academic year running from March through the following February, for instance, or a development contract that began one summer and ended the following January. When material spans multiple years substantially, I inevitably end up with directories of the same name under several years.

~/iCloud Drive/yearly/future

One of my most recent changes was adding a future directory under yearly. It holds material about things I expect to happen in the future but whose timing is still uncertain. If the timing is known, the material goes directly under a specific year instead. Examples include marriage, raising children, postdoctoral research, finding a job, and trips I haven't taken yet. Since these things haven't happened, the contents are mostly wish lists, tips that may come in handy when the time comes, and information about support programs rather than records of the past.

Now that future exists, would chronological be a more accurate name than yearly?

~/iCloud Drive/resources

Things I need to keep but that aren't tied to a particular time go in resources: books, favorite works of art, sheet music, contacts, software, operating-system and application settings, wallpaper images, fonts, document templates, and more.

~/iCloud Drive/tunnel

I use tunnel to move material between devices. Other directories in the cloud hold things up in the “cloud” so I can download them whenever I need them. tunnel, as its name suggests, is more like a tunnel for quickly sharing things between devices down on the ground. Files stay there only briefly in transit before moving to wherever they'll live. I created this directory only recently, after the number of devices I own grew rapidly. I was privately rather pleased with myself for coming up with a name as concise and apt as tunnel.

~/dev

dev contains all the codebases for my research, coursework, side projects, contract development work, this site, and more. It sits outside iCloud Drive because source code like this is usually managed not with a general-purpose cloud service such as iCloud, but with different software called a version control system (VCS).

Imagine you're a developer writing code. If some new code you wrote caused a malfunction, being able to roll back to the last working version would be extremely useful. Better still, imagine being able to inspect word by word what was added or changed in each version, or review and automatically merge the divergent results of several people's parallel work. A VCS provides these features, which ordinary cloud services don't. It can also back up and sync codebases.

What's more, codebases have characteristics that mean they should not be synced through an ordinary cloud service. Some libraries in a codebase—“meal kits” of code someone else has already written, ready for you to use—contain hundreds or thousands of individual files. Use a few libraries and a project's file count can easily run into the tens of thousands. So many files put an enormous load on a sync service, even if each file is small. When I was a junior developer and unfamiliar with VCS, I naively put a codebase on Google Drive. The Drive client started malfunctioning, leaving me in a bind. With a VCS, I can exclude all those troublesome files from syncing in one go.

Naming conventions

I name directories and files according to the following rules.

kebab-case

By default, I give directories and files English names in kebab-case.

This choice is purely about convenience from a computer-science perspective.

① Korean characters in names mean having to switch between Korean and English while typing code or commands, and they can also cause encoding problems.
② Mixing uppercase and lowercase letters can lead to confusion between names that differ only in case.
③ Spaces can cause a computer to interpret a path as multiple strings rather than one. For example, if you want to run a Python file called do something.py and enter python do something.py without putting the filename in quotation marks, your computer may object instead of running it: “There's no file called do. And what's something.py supposed to mean?”

English kebab-case avoids all of these problems. It's even a little more convenient than snake_case (_) because I don't have to press shift to type the character that replaces a space (-). I do sometimes deliberately use _ when I need to separate ideas rather than simply words.

I avoid other characters as much as possible, since I don't know what side effects they might cause. That leaves letters, numbers, -, and _.

Versions

I name different versions of the same document as follows:
① If the work is $n$% complete, the version is v$n$.
② Finished and nearly finished versions are vF (final) and vSF (semi-final), respectively.
For example, a roughly half-finished draft and a nearly finished version of a paper for the 2025 Spring Conference of the Korean Society for Aeronautical and Space Sciences would be named KSAS2025S-manuscript-v50.docx and KSAS2025S-manuscript-vSF.docx, respectively. I actually borrowed this system straight from my advisor. They never explained it or told me to follow it; I just noticed the pattern in the files they sent me, thought it looked good, and copied it. Heh.

Ordering

By default, I don't assign an order to directories or files within the same directory. I use a $n$- prefix only when ordering them is particularly useful. Returning to the spring conference as an example, I made subdirectories for its successive stages: 0-ref (reference materials for the submitted research), 1-manuscript (the submitted paper), 2-registration (conference registration, accommodation, and travel expense claims), 3-schedule (the conference schedule), and 4-presentation (the presentation).

I've had a few chances to see how acquaintances handle numbering differently. One puts a single-digit number at the beginning of every directory name, so they can quickly reach the desired path by pressing n-Enter-n-Enter-... (left hand, right hand, left hand, right hand... The first time I saw it, I thought they were playing the piano). Another built a system with fixed-length numbers, where each digit indicates the position at its level. Knowing the number lets them go straight to the corresponding path. In an archive three levels deep, for example, a directory in the first top-level category and second subcategory would be numbered 120.

Personally, I find it cumbersome to number everything and then renumber all the subsequent directories whenever I want to insert a new one in the middle. I also want to keep paths as concise as possible, so I haven't adopted a universal numbering system. The downside, of course, is that finding a particular path takes longer than it does with my acquaintances' systems.

Closing thoughts

While writing this, I looked up some material on organizing folders, including the video that appeared in my YouTube recommendations above. I found personal tips as well as fully developed systems like the PARA method. Some advice described things I was already doing exactly, as though the author and I had agreed on them beforehand. Some taught me something new; other advice I couldn't agree with at all.

Even with the same computer, we all do different things and have different preferences. So it makes sense to look at many examples, adopt what suits our own circumstances rather than follow any one system blindly, and gradually develop the system that works best for us. I'll end on that perhaps obvious point, in the hope that this post helps you along the way.