There is a certain class of project that developers keep returning to: the text editor. Not because the world needs another one, but because building one teaches you things that reading about editors never will. Joshua Barretto recently wrote about doing exactly this, writing his own editor and then committing to it as his daily driver.
That second part is the interesting constraint. Writing a toy editor is straightforward enough. Writing one you can work in every day is a different problem entirely.
What Daily-Driving Forces
When you use your own tools seriously, friction surfaces immediately. A gap buffer or piece table that felt clever in isolation starts to show its character when you are actually editing files. You discover that the cursor movement you skipped is one you reach for constantly. You learn which abstractions were load-bearing and which were just aesthetic.
This is the value of the exercise. It is not about the editor itself. It is about what the editor teaches you when you are no longer a tourist in your own codebase.
Text editors are also deeply personal software. The assumptions baked into Vim’s modal model, or Emacs’s everything-is-a-buffer philosophy, or VS Code’s extension-first architecture, reflect specific ideas about how people write and think. Building your own means making those assumptions explicit rather than inherited.
The Systems Programming Angle
For anyone interested in systems work, a text editor is a genuinely interesting domain. Gap buffers, rope data structures, syntax highlighting with incremental parsing, undo history as a persistent data structure, rendering to a terminal or a GPU surface: each of these is a self-contained problem with real depth.
You also end up thinking hard about latency. An editor that hesitates, even for tens of milliseconds, feels wrong in a way that a slow web page does not. Input handling and rendering have to be tight. That discipline carries over.
The Practicality Question
The obvious pushback is that this is impractical. Neovim exists. Helix exists. Zed is fast and getting faster. Why build something that already exists in better form?
The answer is that practicality is not the point, at least not initially. The point is to close the gap between using a tool and understanding it. Most developers interact with their editor thousands of times a day without any real model of how it works. Building one, even a modest one, changes that relationship permanently.
And if you stick with it long enough to daily-drive it, you end up with something more valuable than productivity: you end up with software that fits exactly how you think, because you are the one who decided what it should do.
Barretto’s write-up is worth reading on its own terms. But the broader lesson is that the projects worth doing are often the ones that seem redundant from the outside.