About

How I Work

How I Approach Software Engineering

I build systems that work today and remain comprehensible tomorrow. That means writing code as if the next person to touch it knows nothing about my clever solutions—because they won’t. It means choosing boring, proven technologies over exciting, cutting-edge ones. And it means recognizing that the system in production, however flawed, is currently serving real people. My job is to improve it without breaking what already works.

What I Believe

Accessibility is a feature, not a checkbox. Too many teams treat accessibility as compliance theater—running automated scans, fixing obvious failures, calling it done. Real accessibility means designing with screen readers in mind from the start, testing with keyboard navigation, understanding how cognitive load affects users with disabilities. It’s not extra work if you build it in from the beginning.

Simple systems scale better than clever ones. I’ve debugged enough “elegant” architectures to know that simplicity wins. A straightforward data model beats a brilliant abstraction. A clear naming convention beats clever shortcuts. Future engineers—including future me—will thank you for being boring.

Code reviews should teach. A good code review isn’t a gate to pass through. It’s a teaching moment. I’d rather spend 15 minutes explaining why a pattern matters than just marking “change requested.” If the same issue appears repeatedly, the problem isn’t individual developers—it’s missing documentation or unclear standards.

Every legacy system was once greenfield. It’s easy to complain about inherited code. It’s harder to recognize that the decisions made sense at the time, with the constraints and knowledge available. My job is to understand why things are the way they are, then improve them incrementally rather than demanding rewrites.

Security is everyone’s responsibility. You can’t bolt security on after the fact. Developers need to understand common vulnerabilities. Architects need to design for defense in depth. Code reviewers need to catch risky patterns before they reach production. Security teams provide expertise, but secure systems require secure practices everywhere.

Documentation is a love letter to your future self. Six months from now, I won’t remember why I made a particular architectural decision. A comment explaining the constraint I was working around will save hours of archaeology. Documentation isn’t overhead—it’s an investment in velocity.

Production incidents are learning opportunities. When systems fail, there’s a human tendency to find someone to blame. Better to ask: what process failed that let this reach production? What monitoring could have caught it earlier? What documentation would have helped the on-call engineer diagnose it faster?

Estimates are probabilities, not commitments. Software estimation is hard because we’re constantly solving novel problems. “Two weeks” really means “probably two weeks, possibly four, maybe one if we get lucky.” Pretending otherwise doesn’t make schedules more reliable—it just makes teams overpromise and underdeliver.

Good engineers steal shamelessly. No need to reinvent every wheel. If another team solved a problem well, copy their approach. If a library exists, use it. Originality points don’t matter—delivering value does.

The best code is code you don’t write. Before building a feature, ask: is this actually necessary? Can we solve this with configuration instead of code? Can we simplify the requirement? Every line of code is a liability—something to maintain, test, debug, and eventually rewrite.

Development Philosophy

I write tests for logic that matters, not for coverage metrics. I refactor when the pain of working with old code exceeds the risk of changing it. I optimize when profiling proves there’s a problem, not when intuition suggests there might be. I commit frequently with clear messages, knowing that future debugging often starts with git blame.

Architecture Philosophy

Start with the simplest thing that could work. Add complexity only when requirements demand it. Measure before optimizing. Design for observability from day one—logs, metrics, and tracing aren’t nice-to-haves. Plan for failure: timeouts, retries, circuit breakers, graceful degradation. Make the right thing easy and the wrong thing hard through API design.

Leadership Philosophy

Leadership isn’t about having answers—it’s about asking good questions and creating space for others to solve problems. My job is to remove obstacles, provide context, make tie-breaking decisions when teams are stuck, and ensure people have time to do deep work without constant interruptions.

I believe in leading by example: writing code, reviewing PRs, debugging production issues, taking my turn in the on-call rotation. Credibility comes from demonstrating that I won’t ask anyone to do work I’m not willing to do myself.

Accessibility Philosophy

Accessibility is fundamentally about empathy. It’s recognizing that not everyone interacts with systems the way I do. Someone might navigate entirely by keyboard. Someone might rely on a screen reader. Someone might have cognitive processing differences that make complex flows overwhelming.

The best time to think about accessibility is during design. The second best time is during implementation. The worst time is after someone files a complaint. Build it in, test it properly, and advocate for users who often don’t have a voice in the room.

Security Philosophy

Assume breach. Validate input. Escape output. Use parameterized queries. Keep dependencies updated. Fail securely. Log security events. Encrypt sensitive data. Use least privilege. Don’t roll your own crypto. Take automated scanners seriously but understand they’re not sufficient—real security requires thinking like an attacker.

I’ve seen too many teams treat security findings as chores to batch up and handle “later.” Later never comes. Address vulnerabilities when they’re discovered, before they’re exploited.

Beyond Work

Karate

Shodan (1st Dan black belt) in Shito-Ryu, earned in 2003. Karate taught discipline, focus, and that mastery requires consistent practice over years—principles that apply equally to engineering.

Music

Guitar player. Favorite band: Apocalyptica (metal played on cellos—because unconventional instruments playing heavy music is beautiful). Listen to all genres but gravitate toward prog metal, classical, and anything with complex rhythms.

Travel

• Lived in: Mazatlán (Mexico), Mexico City, Atlanta
• Visited: Multiple cities across Mexico, United States (Atlanta, New York, LA, Miami, Orlando, Seattle), Europe (Madrid, Paris, Venice, Milan, Florence, Pisa, Amsterdam, Brussels)
• Next Goal: Japan

Family

Father. My son insists I’m a “Computer Master,” the most accurate title I’ve earned. Balancing family and engineering work teaches prioritization better than any methodology.

Fun Facts

• According to my son, I’m officially a “Computer Master”
• My hometown’s history deserves better than dusty photo albums, so I built Galería Mazatlán