For the past few weeks, I have been syncing my notes folder to GitHub almost every day. The workflow is simple. I write in markdown, save the file, then run a few git commands to push the changes to a remote repository. Most days it goes smoothly. Some days it does not.
The errors are almost always small. A folder I named with a capital first letter, the way I would naturally write a title, turning out to conflict with another folder of the same name in lowercase. A hidden trailing space at the end of a filename, invisible to me but unmistakable to the system. A filename with an underscore in a folder where the convention is hyphens. None of these are dramatic. Each one is a correction, a small adjustment, a polite reminder that I am working inside a culture I did not invent.
What surprised me, the first few times, was not that the errors happened. It was how settled the conventions are. Lowercase letters. Hyphens between words. No spaces. No special characters. URL-style. README.md in capitals because that name carries a specific signal, the kind of file you are meant to open first. Most other files in lowercase, because most other files do not need to shout.
These are not aesthetic preferences. They are working-culture choices, refined over decades of people stepping on each other’s toes inside shared codebases. They have the quality of conventions that have been earned, not declared.
How I got here
I did not set out to become a software developer. I am not one. I work in IT and cybersecurity marketing, and my background is in philosophy. But the past year of working with AI has changed something about how I write and store knowledge.
What people now call “vibe coding” is not really programming in the old sense. It is closer to a conversation with a tool that can build other tools. You describe what you want, you iterate, you adjust. The output is real code, but the process feels less like engineering and more like sketching. AI lowers the cost of trying things, which means more people, including people like me, are now spending time inside the developer’s working environment.
That environment has its own grammar. Markdown for documents. Git for version control. GitHub for storage. Folders organized like small projects, each with a README.md at its root explaining what it contains. Plain text everywhere. The whole setup is built so that humans, machines, and AI can all read the same files without translation.
I started using this setup for personal knowledge management about a year ago. Not because I needed to. Because it solved problems I was tired of having. My folders stay organized. My notes are searchable. My history is preserved. AI can read across my entire archive without any pre-processing.
Once you start living inside that environment, certain conventions stop feeling external. You absorb them. Lowercase is one of them.
Why the software industry went lowercase
The reason is operational. In Unix-like systems, filenames are case-sensitive. README.md and readme.md are not the same file. They are two different files that happen to look almost identical to a human reader. That class of confusion is exactly the kind of error that costs hours to track down, and it is invisible until it is not.
The simplest fix is to make the convention as narrow as possible. Use lowercase. Use hyphens between words. Avoid spaces. Avoid special characters. Reserve capitals for files that genuinely need to stand out. README.md in capitals is not a violation of the convention. It is part of the convention. The all-caps name is reserved for the file most central to the folder, the one a new reader should open first. Capitals carry meaning when they are rare.
This reservation is the part I find most interesting. The developer culture did not abolish capitalization. It allocated it. Most files in lowercase because most files do not need a signal. A small number of files in capitals because they carry a specific role. The result is a system where capitalization itself becomes information rather than decoration.
Compare this to ordinary English prose. We capitalize the first letter of every sentence. We capitalize proper nouns. We capitalize words inside titles, depending on style. The capital letter is everywhere, and because it is everywhere, it does very little work. It signals “this is the start of a sentence” or “this is a proper noun,” but the reader can usually infer both of those things from context.
So one way to read software’s lowercase convention is this. The industry decided that capitalization in filenames was paying for itself less than it cost. Most files did not need the signal, and the inconsistency created bugs. Better to default to lowercase and earn the capital letter only where it carries weight.
The same goal, the opposite answer
The interesting counterpoint is that other industries went the other way for the same reason.
Military telegrams, aviation communications, and early closed captions on television all used uppercase. The reasoning was identical to software’s reasoning. Reduce ambiguity. Standardize the visual texture of the message. Avoid the cognitive cost of letter-case variation. The conclusion was the opposite, but the goal was the same.
What is easy to forget is that those choices were partly hardware decisions. Telegraph machines did not reliably support both cases. Early teleprinters often produced only uppercase. Closed-caption signals on analog television in the 1980s were encoded on a narrow line of the broadcast signal, with limits on character set. Uppercase-only was sometimes a constraint dressed up as a design choice.
Now, decades later, the hardware constraint is gone, but the convention persists. Aviation messages still come through in all caps. Closed captions on news broadcasts still appear in uppercase. The military still drafts in uppercase telegram form. None of these are genuinely necessary anymore. They are cultural fossils, retained because the institutions that adopted them have not had a strong reason to switch.
In contrast, software is young. It came of age after the constraints had been lifted. It got to choose its convention from a position of options, and it chose lowercase for ergonomics rather than necessity.
If you read uppercase as shouting and lowercase as speaking at normal volume, the institutional industries are still shouting because their telegraphs once had to. Software speaks at normal volume because it was born after the telegraph era.
What the reformers tried, and what survived
The instinct to simplify written language is not new. In the 1920s, the German typographer Jan Tschichold and the broader Bauhaus circle argued for Kleinschreibung, lowercase-only writing. Herbert Bayer designed a typeface called Universal that contained no capital letters at all. Their arguments were practical. The double alphabet was inefficient. Capital letters were a vestige of stone-carved Roman inscriptions, kept around in modern type by sheer convention. Removing them would simplify learning, typesetting, and typing.
In the same century, Esperanto attempted something more ambitious. A constructed language designed to be neutral, easy to learn, and free of the irregularities that natural languages accumulate. The goal was a shared second language for the world.
Neither effort succeeded at the scale its founders hoped. German still capitalizes its nouns. Esperanto did not become a global second language. The 20th century is full of these attempts, from constructed languages to spelling reforms to alphabet redesigns, and most of them are now historical curiosities.
It would be a mistake, though, to read those movements only as failures. They simply succeeded at a smaller scale than they aimed for. Bauhaus typography did not reform German, but it permanently changed how designers think about hierarchy, white space, and ornament. Esperanto did not replace national languages, but it seeded a long lineage of ideas about constructed languages, neutrality, and accessibility.
What I think those movements got wrong is the level at which they pitched the change. They asked the world to adopt a system. The world rarely does. What works instead, almost every time, is what the software industry did. Set a convention inside a domain where the convention solves a real problem. Let it spread to the people for whom it is useful. Accept that it stops at the domain boundary. Do not try to convert anyone.
That kind of change is descriptive rather than prescriptive. It says, “here is what we do, because it works for us.” It does not say, “this is what you should do.” And precisely because it does not demand adoption, it tends to attract it.
The lowercase convention in software is exactly this kind of change. It started as an internal solution to internal problems. It spread to URLs because URLs are written by developers. It spread to filenames everywhere because files cross domain boundaries. It is now the default for any string a machine has to parse cleanly. Nobody legislated this. Nobody had to.
What it feels like to write this way
There is a moment, after you have been writing in lowercase for a while, where you stop noticing it as a choice. The shift key becomes optional. Sentence starts blur into sentence middles. Proper nouns lose their visual badges. The text on the page begins to look more like the way you actually think before you dress your thinking up for an audience.
I do not write all my prose in lowercase. The essays I publish, including this one, follow conventional capitalization, because the audience expects it and because the convention does carry some real information in long-form text. But my daily notes are in lowercase. My commit messages are in lowercase. My folder names are in lowercase. Personal letters and informal posts are often in lowercase too, with capitals reserved for the moments when they leave the personal zone.
What I get from this is harder to name precisely. The closest description I can offer is this. Capital letters are a small, constant performance. Each one says, in a small voice, “I am the start of something” or “I am a proper noun” or “I am important.” Removing them does not remove the information, but it removes the performance. The text becomes a record of thinking rather than an arrangement of declarations.
Signing a personal note as “tom yonashiro” instead of “Tom Yonashiro” is a tiny example of this. The lowercase signature feels closer to the person, less like a letterhead, more like a handwritten note. It is not a serious change. It is a small relaxation of formality. But the cumulative effect of many such small relaxations across an entire personal writing practice is real.
There is also a cognitive saving, though it is smaller than the psychological one. The shift key takes a moment. The decision about whether to capitalize takes a moment. Multiplied across thousands of words a week, those moments add up to enough friction to be worth noticing. AI, once you allow it into the workflow, can correct anything that needs correcting at the output stage. So the lowercase draft does not become the final output by accident. It becomes the final output by choice, in the cases where the personal voice is the point.
A borrowing, not a movement
I am not proposing that anyone adopt this. I am writing about it because I noticed it, because the noticing came from a working environment that turned out to be teaching me something, and because the philosophy behind it is interesting on its own terms.
The lowercase convention in software solved a specific problem in a specific domain. It did not try to spread. It just turned out to be useful enough that it spread on its own. The version I have adopted in my personal writing is a borrowing from that domain, applied where it suits me, and kept out of the places where it would create friction with shared conventions.
That is the form of language change I find compelling now. Not the totalizing reforms of the early 20th century, with their ambitions to redesign the alphabet or replace national languages. Something smaller. A house style. A personal operating system. A convention you adopt because it serves you, and that you set aside at the boundary where it would stop serving anyone else.
The small letter, in this version, is small on purpose. It is not the first letter of a manifesto. It is just a letter, written the way I prefer to write it, in the contexts where the preference is mine to make.
What I have learned from sitting inside the software developer’s environment for the past year is that the most durable practices are usually the ones that did not set out to be durable. They were solutions to local problems. They earned their place by working. They spread because they were useful, not because anyone insisted.
That is what the plain logic of lowercase looks like to me. A working culture’s small, considered choice, borrowed for personal writing, kept where it helps, set aside where it would hurt. Nothing more, and nothing less.
Image: StockCake
Tom’s Blog 