I'm Roland Rodriguez.

I spend more time than I should testing terminal emulators and mapping keyboard shortcuts. I can't help it. I want to understand why some tools feel right and others don't, even when they do the same thing. That obsession shapes everything I build.

My path wasn't typical. While consulting globally for Avanade, my family lived aboard a sailboat for fourteen years. Not as a sabbatical, just as home. We were moored at Shilshole Bay Marina, and my wife and I opened an espresso bar there, in a location where food service businesses historically fail. It's still thriving a decade later. When my son was diagnosed with leukemia, I started a Microsoft Gold Partner consultancy and ran it from his hospital room for two years.

Those constraints taught me questions that strategy sessions miss. On a boat, you can't ignore physical reality. Storage is finite. Weight affects stability. Every system has dependencies you have to understand before things break. The espresso bar taught similar lessons: you can design the perfect workflow, but it doesn't matter if the person on bar can't execute it under pressure during morning rush. The hospital room added another dimension. When critical decisions happen fast with incomplete information, you develop deep respect for tools that surface the right data at the right moment.

This shows up in my open source work. In rusty_paseto, you physically cannot use the wrong key type with the wrong token version. The compiler rejects it. The wrong thing is impossible, not just discouraged. In acton-reactive, if your code compiles, critical classes of runtime errors cannot occur. Both projects trade flexibility for guarantees. The questions stay consistent: What makes a CLI feel intuitive? When should an API be opinionated versus flexible? How do you encode domain knowledge in an interface instead of documentation?

I built the technical foundation over three decades. CompuServe in 1995, teaching myself C and Java between support calls. RealNetworks during the streaming wars. Microsoft's Azure team in 2009, when cloud was still explaining itself. At AWS, they created a role for me to lead global Rust strategy. Hundreds of teams, thousands of engineers. I also served on the Doc Writing Bar Raiser leadership team, helping shape Amazon's document culture. A twenty-year principal called one of my docs “the best document I've ever read during my time at Amazon.”

But the résumé matters less than what I learned: the difference between clever architecture and maintainable architecture, how constraints actually liberate design, why the best tools feel invisible.

I write here about developer experience and constraints. If any of that resonates, stick around.