The perennial software dilemma: build for learning or ship for use.

A few years ago, I spent months on deep dives into security and privacy tools that would consume most of my attention. I did a lot of experimentation, and each experiment taught me a new piece of software or way of thinking. Whether it was understanding how encryption worked, or how network sniffing was used, how to harden a system, or to think through potential threats, each experiment was steeped in rich lessons. The exception was that none of them ever crystallized into something I ended up shipping into the world. I simply lost interest in the tools, and they faded away within weeks or months. The pattern established the rule that building for learning never routes into shipping for use.

In the past two years, I have immersed myself even deeper into experimenting with AI. Almost all of my attention has focused on how language models work, how we train them, or how we're building agentic architectures. Every evening ended with happy hours tinkering with new models and architectures. The reason the learning feels so rewarding, and so good, is because as an electrical engineer, I have a relatively strong systems-level intuition. I was never afraid to pull back the hood and learn how things worked. When it comes to AI, I'm doing the same. I am also learning how to deal with the real bottleneck, as it turns out, with the tools and resources needed to actually ship. It's almost poetic because the constraint is literally in tokens, which means I can't do everything, and I need to keep my bets small and focused. It's a system-level constraint that closely mirrors the resource dilemma that software entrepreneurs face. Even with this constraint, the pattern persists: shipping still loses to the magnetic pull of building for learning.

Humanoid robots are fascinating. There's a lot that I believe is still to be discovered there, and it's going to be compelling to explore them now that I'm more than halfway through my software journey. I'm not there yet, but I'm already making mental space to shift attention to what's next. Again, this is something I never end up shipping, just exploring, just building, just fading. The dilemma is getting recursive. Is it possible that humanoid robotics becomes another idea that dies in a month?

I think this dilemma crops up with many tinkerers who draw their deepest motivation from the build itself, not from a larger plan. It is far more pronounced in some fields than in others; security and privacy, AI, robotics, but also many others. I suspect it is deeply tied to how the electrical engineering mindset is geared towards systematic design and architecture. An engineer doing applied research will prioritize coming up with a systematic way to design and build something, which should theoretically break the cycle I've fallen into. But rarely does this in practice due to the pull of curiosity. In order to ship, you need to stop exploring and have a hard cutoff. I'm not there yet.

But for now, the learning is rewarding enough that the dilemma is an end cost, not a catastrophe. I'll eventually have a true software transition, and at that point, I'll have to make a conscious decision to stop tinkering and start shipping. Given my escalating obsession with humanoid robots, it might already have started. I have some hope the EE training will eventually supply the systematic rigor needed to ship, but the joy of the build and the learning it brings will always be its own end.