I've always been a builder.
Even as a child, I would take apart old toys and attach pieces of them to other toys. I'd modify things, upgrade them, and try to figure out what I could make them do.
Looking back, that's probably what eventually led me into Software Engineering.
I've always enjoyed taking something apart, understanding how it works, finding the problem, and figuring out how to make it better.
Over the years, that skill grew.
I taught myself how to write software. I learned how to track down those obvious-but-somehow-frustrating bugs. I moved through different areas of technology, including QA, Automation, and Software Engineering.
And eventually, I started building Ramen.
When I first published Ramen, I thought the hard part was building the application.
Turns out, that was only the beginning.
Building something is only half the job
Once Ramen was out in the world, I started using it differently.
I wasn't just looking at it as a project I had built anymore. I started looking at it as a QA tool.
And when you start looking at something from the perspective of the person actually using it, you notice things you simply don't see while you're building it.
The interface worked, but it didn't quite feel like the environment I wanted Ramen to be.
Some workflows made sense to me because I knew how the application worked internally, but that didn't necessarily mean they were intuitive.
Some parts of the UI were functional, but didn't communicate what they were actually doing.
And that made me realise something:
I needed to stop looking at Ramen as its creator and start looking at it as its user.
So I started taking it apart.
Not literally this time, but in the same way I've always approached things.
What works?
What doesn't?
What's confusing?
What can be simplified?
What can be rebuilt?
Making Ramen feel like a development environment
That process led to a fairly significant rethink of the Ramen experience.
One of the biggest changes has been the interface itself.
I wanted Ramen to feel more like an actual development environment.
Not because I wanted to copy an existing IDE, but because developers and QA engineers already have certain expectations about how these environments work.
The way projects are organised.
The way source control is represented.
The way different parts of a workspace interact with each other.
The previous design was functional, but it didn't quite have that feeling yet.
So I started rebuilding it.
The Git experience was redesigned to actually resemble a Git container rather than simply presenting Git-related information in a UI.
The branching system was redesigned.
Various parts of the interface were reworked to make the overall experience more intuitive and cohesive.
None of these changes are necessarily huge features on their own.
But together, they change how Ramen feels when you're actually using it.
And that's something I've become much more conscious of while building this project:
Functionality is only part of building a good tool.
The experience around that functionality matters just as much.
Building with users, not just for them
The other major change isn't really a visual one.
It's how I want Ramen to evolve.
I've added a feedback system that allows users to provide feedback directly from within Ramen.
Because I don't want to build Ramen in isolation.
I don't want to disappear into a room, decide what I think people need, build it, release it, and then repeat the process.
I want the people actually using Ramen to have a voice in what it becomes.
If something is confusing, I want to know.
If something is frustrating, I want to know.
If something works really well, I want to know that too.
The goal is for real-world usage to become part of the development process itself.
And this became particularly important once I released 0.1.0-preview.1.
Putting Ramen into the hands of other people
The preview release was an important step for Ramen.
Until that point, a lot of the testing was happening from my perspective.
I knew how Ramen worked.
I knew where things were.
I knew what certain controls were supposed to do.
That makes it surprisingly easy to overlook problems.
Someone using the application for the first time doesn't have that context.
They don't know what I intended.
They only know what the application communicates to them.
And that's exactly what I needed to learn.
Where do people get confused?
What workflows feel natural?
What feels unnecessarily complicated?
What breaks?
What features do they immediately understand?
And perhaps most importantly:
Does Ramen actually feel useful?
Releasing the preview wasn't about declaring Ramen finished.
It was about getting it out of my head and into the hands of people who could actually challenge the assumptions I'd made while building it.
And once that happened, the process changed again.
Taking it apart again
This is probably the part of building software that I enjoy the most.
Taking something apart.
Figuring out why it isn't working the way it should.
Finding the frustrating parts.
Understanding the problem.
Then rebuilding it.
Ramen has given me another opportunity to do exactly that.
Except this time, I'm not taking apart an old toy.
I'm taking apart a product I've built myself.
The difference now is that I'm not doing it entirely on my own.
I'm building.
I'm testing.
I'm listening.
I'm learning.
And then I'm rebuilding.
That's become the development cycle for Ramen.
And it has changed how I think about the project.
I'm not just trying to add more features.
I'm trying to make the features that already exist feel better.
I'm trying to make the workflows more natural.
I'm trying to remove friction.
I'm trying to understand what people actually need from a Quality Development Environment rather than assuming I already know.
The next release
That brings me to the next release of Ramen.
I'm moving away from traditional semantic versioning for Ramen and towards a date-based versioning system.
The idea is simple: the version should tell you when the release belongs to, while the release and patch numbers identify the iteration.
So rather than continuing with 0.1.0, 0.1.1, and 0.2.0, Ramen is moving towards versions such as:
2026.09.20.1
It's a small change, but it reflects how I want to approach Ramen going forward.
Ramen isn't a project where I'm trying to hit some arbitrary number before I can call it "real".
It's going to keep evolving.
Releases will happen as the product develops, and the version should provide a simple reference point for where that release sits in the history of Ramen.
And this release represents another step in that process.
This is still just the beginning
There is still a lot to do.
There are features I want to build, workflows I want to improve, rough edges I want to smooth out, and plenty of things I haven't even thought of yet.
But that's part of the fun.
Ramen started as an idea for a Quality Development Environment for QA testers.
It became an application.
Then it became something I could put into the hands of other people.
Now it's becoming something that can evolve with the people using it.
And I think that's the biggest change I've seen in Ramen so far.
I'm still taking it apart.
I'm still rebuilding it.
I'm still finding things that don't work the way they should.
But now there's a feedback loop.
Build.
Test.
Listen.
Rebuild.
Repeat.
The building isn't over.
It's just getting started.
Top comments (0)