We all build cool things, but the real test of software isn’t the rush of writing code—it’s whether our work still stands months or years later. Great engineering depends on time, trust, and the feedback we’re often not getting. When teams close the disconnect between what’s asked for and what’s actually needed, we end up with software that lasts, solves real problems, and avoids the discount bin long before its time.
Today I had a chance to put my logic, discipline, and outlook to the test. Beyond being passionate, careful, and detail-oriented, there’s a moment many of us hit where we write code like we’re on cloud nine. It feels great—especially when you’re trusted and given space by the people you’re building with.
But the real measure of whether all that energy becomes a market-ready solution is judged by one thing: time.
My advice to other software engineers:
We all build cool stuff, but we’re ultimately judged by what we’ve built lately that still exists.
It takes a moment to swallow that, but this mindset has helped me make clearer decisions in and around code. There are always things no one asked for—sometimes a lot of them—that are simply common-sense “do-nows.” Depending on the day, bringing those up might get me a “do whatever you need,” or the complete opposite. Over time, I’ve learned not just to listen to what’s presented, but also to what’s missing, what’s unseen, and what will matter when we meet again. All while respecting time, cost, and scope.
Back to the main idea. Some of the best things we’ve ever built get tossed in the discount bin long before they naturally expire. So I want to focus on what we can control.
Getting feedback shouldn’t be a fight.
Especially in an industry overflowing with “fast-forward vocabulary”—or what we conveniently call agile.
Throughput shouldn’t be hard to understand. We’re all supposed to be moving work from left to right. Maybe we put too much weight on a single work item. Maybe if developers weren’t forced to treat every card like a make-or-break event, the system would flow more naturally. The real safeguards come from using the feedback loop, not skipping it.
Unpopular opinion: non-technical team members often have access to non-production environments, but they tend to hyper-focus only on the features they personally care about. Developers rarely get that luxury.
I truly believe leadership would be surprised by what happens if we close that disconnect. The result wouldn’t just be smoother processes—it would be more creative, durable, meaningful software. The kind that actually solves real problems—and lasts.