Everything Lives in Downloads

A student shares their screen in office hours. The build will not run, and I ask them to open the project folder.

They open Downloads.

Not a project folder inside Downloads. Downloads itself: four thousand items sorted by date, a scrollbar the size of a grain of rice. Somewhere in there is a directory called hw3, and also hw3 (1), and also hw3-final, along with every PDF, every zip, every screenshot, and eleven copies of the syllabus. They scroll for a while. They find it. The build fails, because the assignment expects to run from inside the project directory and they are two levels above it.

I have watched some version of this happen more times than I can count, and my first instinct — the bad instinct, the one I try to catch — is to tease. To make a joke about digital hygiene, or mutter something about kids today. It is an easy laugh and it teaches nothing. Worse, it aims at the wrong target. The more I look at this, the less it resembles a mess and the more it resembles a method. Just not one that survives contact with a compiler.

It is not laziness

Start with the generous reading, because the generous reading turns out to be the accurate one.

The Downloads folder is sorted by recency. That is a real organizing principle, and for most of what a person does with a computer it is a good one: the thing you need is almost always the thing you touched most recently. Everything else is a search away, search is fast, and search does not care where the file lives.

Watch a student work this way and you notice they are not lost. They find things. They find them by typing three letters into a search box, which is not obviously worse than remembering that a file lives in ~/school/fall26/326/hw3/. It is a different retrieval strategy: associative rather than spatial. Instead of where did I put it, the question is what was it called.

For photos, music, mail, and essays, that strategy is nearly free. It does not collapse until you reach for a toolchain.

Where the model went

It is worth asking where the spatial model went, because it did not fall out of anyone’s head. It was never put there.

Consider what a student who is twenty this year grew up using. In K-12 there is a good chance the school issued a Chromebook, where the real storage is Drive, the local disk is scratch space that gets wiped, and where is it saved has no answer because the question never comes up. On a phone, the filesystem is not so much hidden as absent: photos live in Photos, songs live in Spotify, notes live in Notes. Each app owns its data and hands you a list. Google Docs has no save dialog at all. There is nothing to name and nowhere to put it.

None of these are mistakes. They are enormous usability wins, and for most people most of the time they are the correct design. The filing cabinet was always a metaphor anyway, invented so that office workers in the eighties would have something familiar to hold onto. Nobody owes it loyalty.

This is well-trodden ground. The Verge ran a piece in 2021, File Not Found, about STEM professors discovering that their students had no mental model of directory structure at all. It landed hard because so many instructors recognized their own classrooms in it. What struck me then, and strikes me more now, is that those students were not confused about computers. They were fluent. They were confused about one specific abstraction that their tools had spent a decade carefully hiding from them.

Why it is different for us

Here is where I stop being relaxed about it.

In most disciplines, this is a tidiness issue. You can write an excellent history thesis out of a Downloads folder. In computing, the hierarchy is not a convention we can take or leave. It is one of the core abstractions the operating system actually exposes, and a startling amount of our tooling sits directly on top of it.

A shell has a working directory. That is the entire premise. cd and .. and ./run.sh are meaningless without a model of location — not a vague sense that files exist somewhere, but a specific belief about where you are standing and what is around you.

A git repository is a directory tree, plus history. A student who cannot picture the tree cannot picture what git is tracking, which is why “just commit your work” so reliably produces a repository containing one folder containing another folder containing the actual project.

A compiler resolves include paths. Node resolves modules by walking up the tree. Docker ships a build context, which is a directory, to the daemon. A relative import in Python means different things depending on where you launched the interpreter. Deployment is very often copying one directory onto another machine and hoping the shape survived.

So when the build fails and the error says file not found, we call it a path problem. It usually isn’t. It is a worldview problem wearing a path problem’s clothes. You cannot debug your way to a file if you do not believe files have locations.

The uncomfortable part

I should admit something, because it undercuts the lecture I might otherwise be tempted to give.

I don’t type paths either.

I jump between directories by typing three characters at a tool that guesses from my history. I find files by fuzzy-matching fragments. I search a codebase rather than navigating it. If you watched my hands and not my head, I would look exactly like the student in office hours: recency and search, all the way down.

The difference is not virtue, and it is worth naming precisely rather than waving at it. When I type z 426 and land in the right directory, that works because there is a 426 directory, it has a shape I chose, and I could draw it on a whiteboard from memory if the tool vanished tomorrow. The shortcut rides on top of a map. Take the map away and the shortcut is not a shortcut any more; it is the only thing you have, and it fails silently the moment you need to reason about where rather than which.

That is the real distinction: search on top of structure, versus search instead of structure. From the outside the two look identical. Under load they behave nothing alike.

The filesystem is not going away

It would be convenient to believe this is a transitional problem: that the next generation of tools will hide the filesystem from programmers the way phones hid it from everyone else, and the gap will close on its own. I don’t think so.

Every operating system that matters in computing still organizes its world as a tree of directories with permissions attached. Servers do. Containers do. The cloud machine running a student’s deployed project does. None of that is on its way out, and anyone studying computing in any form, whether software engineering, data science, security, or research computing, is going to spend their working life inside it.

AI does not change this. If anything, it raises the stakes. An AI coding assistant like Claude Code works inside a directory. What it can see, what it can change, and what it has to ask permission to touch are all defined in terms of directories and file permissions. A student who launches it from their home folder, or from Downloads, has handed it a very different scope than one who launches it inside the project, and may not realize they made a choice at all. When it reports that a file is outside its working directory, or asks before writing somewhere, that message is only legible to someone who already holds the model. Everyone else clicks yes, or gets stuck. Either way, they are at a disadvantage before they have written a line.

There is also a better reason to teach it than any particular tool. A directory tree is not really about files. It is a way of organizing knowledge: things live inside other things, names only mean something relative to where you stand, and a good structure makes the next piece of work easy to place. That model shows up in package namespaces, in URLs, in module systems, in the table of contents of a textbook. It is worth knowing for its own sake, independent of any application, and that alone makes it a reasonable thing to teach on purpose rather than hope students absorb.

Bridging the gap

If the model is not arriving on its own, a few things seem necessary.

Teach it as a concept, not as tidiness. A lecture about keeping your desktop clean lands as a scolding and changes nothing. A lesson about how the operating system names things, what a working directory is, and how absolute and relative paths resolve lands as computer science, because it is.

Start from what students already do well. Search and recency are real strategies, and students who use them are not doing it wrong. The useful move is to show that structure is what makes search dependable, rather than to present structure as its replacement.

Make the tree visible. Most students have never seen their files as a tree. Drawing a project’s layout, running tree, or predicting where a relative path will land before running a command turns an invisible structure into something they can reason about.

Teach permissions alongside location. Who can read a file, who can write it, and what is allowed to execute are the same questions an AI agent’s permission prompts are asking. Students should recognize them as such.

Let real tools supply the consequences. A git repository, a build system, or a container has a shape, and the shape matters. Work that only succeeds when the structure is right teaches the structure faster than any explanation.

Leave the Downloads folder alone. It is a perfectly good inbox. Things arrive there; that is its job. The goal is not to empty it. The goal is for students to know that Downloads is one place among many, with a location of its own, rather than the only place there is.

Where first?

None of this is controversial on its own. Most instructors, asked directly, would agree that students of computing need to understand the filesystem. The harder question is whose job it is.

The introductory programming course is the obvious candidate, and also the most crowded. Those first weeks already carry syntax, logic, tooling, and the ordinary difficulty of learning to think like a programmer. A dedicated tools course addresses the problem squarely, but often arrives a year or more in, after the Downloads habits have set, and is frequently optional. Earlier still, in high school, is where the gap actually opens, and it is also where the tools students are given hide the filesystem most completely.

Each answer has a cost, and the default of teaching it nowhere in particular has the largest one: every later course assumes the model is already there, and each discovers, one office hour at a time, that it isn’t.

So the question is not whether to teach it. It is where we teach it first.