Making Atom Great Again (And Learning Rust While I'm At It)
I have three projects approaching pre-production. Each one in that beautiful, terrifying phase where things are starting to mature, users are starting to notice, and every decision suddenly carries weight.
So naturally, the only reasonable thing to do is start a fourth one.
And not a small one. Not a "weekend script" or a "let me automate my newsletter" project. No. I want to build a code editor.
Yes. A code editor. In 2026. While Cursor, Zed, VSCode, and JetBrains are all sitting there, perfectly capable of handling whatever anyone throws at them.
Let me explain.
The VSCode Fatigue
I wrote about this recently — corporate VSCode is a fancy notepad. But even outside corporate walls, my own personal VSCode setup has started to feel… heavy. Bloated. Slow to start. Configured to death across machines that never quite agree on which extensions are doing what.
It's not bad. It's just tired. Like a car you've owned too long. Still gets you there, but every drive reminds you it's time.
Then I tried Zed. And damn — that thing flies. Native speed, instant feedback, the kind of responsiveness you forget editors are supposed to have. But Zed is opinionated, and the extension ecosystem is still young. Years away from VSCode's catalogue.
Meanwhile, somewhere in the back of my mind, Atom keeps whispering. Yes, that Atom. The one GitHub killed. The one that introduced a generation of developers to the idea that an editor could be hackable, friendly, and opinionated about being unopinionated. It had character. It had soul. It was slow and it was loved anyway.
You see where this is going.
The Obviously Sensible Idea
What if you took Zed's lightning speed, kept VSCode's extension system (because nobody wants to rebuild that ecosystem from scratch), and brought back Atom's hackability and design philosophy?
That's the project. That's the pitch. That's the thing I'll be building after hours, on weekends, between shipping the other three products that are also shouting for my attention.
I know how this sounds. I'm aware. I've been writing about scope reduction and focus and "start easy" for months. And here I am, voluntarily picking the largest possible scope on the planet.
But hear me out — because this isn't really about the editor.
Why I'm Actually Doing This
The editor is the vehicle. The skills are the destination.
I want to grow in directions my current projects don't push me. Building this thing, slowly, properly, is going to force me into territory I haven't been in for a while.
Rust. I've been circling Rust for years. Reading about it, nodding along, never committing. A project like this — performance-critical, systems-level, the kind of thing where Rust actually earns its hype — is the right excuse to finally learn it for real. Not tutorial Rust. Production Rust.
Product management at the deep end. When you're building an editor, every decision is a product decision. What gets in the way? What stays out? What's the default? Who is this for? You can't hide behind "the framework decided." There is no framework. You are the framework.
Vision and long-term thinking. Editors aren't six-month projects. They're not even one-year projects. They're decade-long commitments. That changes how you plan, how you prioritise, how you communicate. It's a completely different muscle than shipping a SaaS feature.
Marketing for something with no user yet. This is going to be the hardest part. How do you build interest in something that doesn't exist? How do you tell a story about a tool nobody asked for? That's a skill I genuinely want to develop, and the only way to learn it is to do it.
The next million-dollar idea. (Laugh.) Look, I'm not betting on this becoming a business. But every long project I've ever worked on has surfaced ideas I never would've found sitting still. Side projects are how you stumble into the next thing.
The Plan: Slow, Open, Collaborative
Here's where I have to actually listen to my own advice.
Start easy. I know. I'll write that on a sticky note and put it on my monitor. The first version is not going to be a competitor to anything. It's going to be the most embarrassingly minimal editor you've ever seen. A window. Text. Saving files. That's it. From there, one piece at a time.
Open source from day one. No "I'll open it once it's clean" trap. The repo goes public the moment there's code. If anyone wants to follow along, fork it, laugh at it, contribute to it — the door is open.
Build it with people who get it. I'm hoping this attracts a few like-minded developers — the ones who also miss what Atom felt like, who care about tooling, who want to learn Rust, or who just want to hack on something with no pressure and no roadmap. If that's you, find me.
Long release cycles, public progress. I'll keep writing about it here. The wins, the dead ends, the moments where I realise I bit off more than I can chew. Especially those moments. Those are the interesting ones.
The Real Reality Check
Three projects in pre-production. A fourth one with a ten-year horizon. A full-time consulting business. A blog. A life that occasionally includes sleep.
Is this insane? Probably. Is it sustainable? We'll find out. Am I going to fail at parts of it? Almost certainly.
But here's the thing — I'd rather fail at something I genuinely care about than coast on something safe. And the worst-case scenario isn't "the editor doesn't ship." The worst case is I learn Rust, sharpen my product instincts, build something in public, and meet people I wouldn't have met otherwise.
That's not a worst case. That's just a slower kind of win.
So yes — I'm making Atom great again. Or trying to. Or learning a lot in the attempt.
If you want to come along for the ride, the repo is already up. Bring your opinions. Bring your Rust questions. Bring your nostalgia.
Just don't bring a roadmap. We're starting easy.