Time for some change and C++
I’m about 20 years into my software development career, and lately I’ve been feeling a quiet sense of saturation.
Most of my work has lived in familiar territory—Java for the most part, with phases of C#/.NET, Node.js, and more recently Go. The problems have been interesting, the systems meaningful, but the shape of the work has remained largely the same: database-driven applications, CRUD-heavy workflows, REST or GraphQL APIs, deployments on AWS and Kubernetes, and layering on patterns like DDD or XP. Even the newer trends—like what people now call “vibe-coding”—seem to fold back into that same mold.
At some point, it started to feel less like exploration and more like repetition.
I found myself wanting something different—not necessarily bigger or better, just… closer. Closer to the machine. Closer to how things actually work. I missed the feeling of building something from more fundamental pieces, of tinkering without too many layers of abstraction in the way.
That’s what led me to C++.
Before settling on it, I spent a fair amount of time weighing it against Rust. Rust is compelling in many ways—its focus on safety, its modern design, the strong community around it. But I kept coming back to C++. There’s a certain openness to it, a kind of unopinionated power. It doesn’t try to protect you as much, and that can be dangerous—but it also forces you to engage more deeply with what you’re doing. Right now, that’s exactly what I’m looking for.
Starting over, in a way, has been both humbling and refreshing. There are moments where nothing makes sense—where memory models, undefined behavior, or template errors feel like a different language entirely. When that happens, I’ve learned to slow down. Sit with the confusion a bit. Break things into smaller pieces. Let the understanding arrive gradually instead of forcing it. It’s not always efficient, but it feels more honest.
Interestingly, my past experience hasn’t gone to waste. Concepts from Java and Go often act as anchors—points of familiarity that help me reason through what’s happening, even when the mechanics are very different underneath.
What’s made this journey especially meaningful is tying it to something I care about outside of programming.
I’ve always had a deep interest in electronic dance music. So instead of learning C++ in isolation, I’ve been using it as a way to explore digital audio—experimenting with sound, trying to understand synthesis, and slowly working toward a personal goal: building a program that lets me record, shape, and play with my own sounds and ideas.
That decision changed everything.
It made me realize that learning a language alone isn’t enough. The real depth comes from understanding the domain you’re working in. For me, that’s meant spending time with the fundamentals of sound, digital audio theory, signal processing, codecs, and audio engineering. It’s a whole different world, and without it, the code would feel empty—like I’m building tools without understanding what they’re truly for.
If there’s one thing I’d suggest to anyone thinking about moving into systems programming—or really, learning anything new—it’s this: anchor it in something that genuinely interests you. Build something. Anything. A small game, a tool, a hardware experiment, a music app, a simulation. It doesn’t have to be original or ambitious. What matters is that it means something to you. That connection makes the hard parts easier to sit through, and the small wins much more satisfying.
I don’t have a clear destination in mind yet. And maybe that’s the point. For now, I’m just following my curiosity—taking it one concept at a time, one experiment at a time—and seeing where it leads. If you’re on a similar path, figuring things out as you go—happy hacking.