About

About Bryan

Staff software engineer focused on distributed systems, performance, and healthy engineering cultures.

Hi, I’m Bryan. Staff Software Engineer. 17 years in, mostly at startups, mostly working on things that didn’t exist before.

My current work is in encrypted search. The problem sounds simple: search over data without decrypting it. The implementation is not. I worked with researchers to take homomorphic encryption into a production-grade distributed system — C++ algorithm implementation, encrypted query execution on Spark, gRPC service architecture, and the full CI/CD and observability stack around it. I also lead the core engineering team, so there’s a management layer sitting on top of the IC work. I try not to let either half hollow out the other.

Before that, I spent five years building real-time situational awareness infrastructure at a small defense startup. Distributed backend, browser SPAs (AngularJS first, then React), iOS and Android clients, automated AWS deployments, a license server, and a GPS-based behavioral analytics system that ended up patented. That era was good for learning that “full stack” isn’t a resume line — it’s a responsibility.

Earlier in my career I was at JHU Applied Physics Lab doing defense-oriented work: radar simulations in Java with performance-critical extensions in C++, and a multi-system performance assessment platform for analysts. Good place to learn that domain correctness is a hard constraint, not a preference.

Stack-wise I’m mostly in Java and C++, with TypeScript and Python in regular rotation. Spring Boot, gRPC, PostgreSQL, Spark. Terraform and Docker on AWS and GCP. The configuration library and Maven installer plugin I maintain are small, precise tools that solve annoying problems well — which is also my preferred engineering aesthetic.

The other part of the job I care about is the team side: real code reviews, design docs that are worth writing, and coaching engineers who are trying to find their direction. I’m not interested in teams that ship fast and silently accumulate debt. Sustainable pace with actual standards is the goal.

Why “Empty Catch”?

Empty catch happens to everyone. You skip the log line, a critical error escapes to production quietly, and nobody knows why until it’s already a problem. It’s not a sign of a careless engineer — it’s just the kind of thing that slips through. The name is a reminder to own it, fix it, and not spend energy on blame.