Trained to listen: where my engineering judgment comes from

When I was a sophomore at South Eugene, the local sports page ran a headline about me: "Doubts don't sink South sophomore." The nine posts before this one are about seek latency, contrast ratios, tap targets and video codecs. This one is about where the judgment underneath them came from, and most of it was not learned at a keyboard.

Where does the engineering come from?

From the house. I was born in Eugene in 1988, the same year my father Ulrich moved Advanced Relay Corporation, his protocol software company, here from Berkeley. He had escaped East Germany, got his family out, and travelled the world installing early hardware and software systems before he founded ARC. I grew up with two immigrant engineers, an East German father and a Mexican mother, both of whom made things for a living, in a house where no dream was too big. The studio is named after him, and the baton post is the long version of why.

I wrote my first lines of code at fourteen, in 2002. From 2005 I was the web administrator inside the family company, building and maintaining the site for a protocol software firm and producing the template for its new one, and in the same year I started ER Designs, which ran for eleven years of fully custom websites and printed marketing for clients and nonprofits. I picked up a new technology on nearly every build. Between 2010 and 2012 I built client web applications front to back for a small shop in Gresham, and in 2011 I taught graduating photography students the fundamentals of web design while each of them built a portfolio site.

Somewhere in the 2010s my father and I started an app together. GreenGO was going to map every fruit tree in the neighborhood, the fruit free for the picking. We never finished it. It still says everything about the house I grew up in.

What did tennis have to do with it?

Less than a headline suggests, and more than I understood at the time. I grew up travelling the country for junior tournaments, and a tournament is a long lesson in what you do when the plan stops working in the second set, in front of people, with nobody allowed to help. You find out early what your defaults are under load. I keep the headline because it names the mechanism in five words, and the mechanism is the part I still use.

Years of competing gave way to years of struggling. I struggled with addiction and personal hardship, overcame it, and got into recovery in 2014. That is the full account on my resume, and it is accurate.

It is also a summary. The plainer version is that I used to struggle with food, and I sometimes still struggle with body image. Worth saying once, here, because it is in the present tense. Recovery is not a room I walked out of in 2014. It is a practice, and twelve years on some of it is still practice. That turns out to matter for how I build. Software for people in difficulty tends to be drawn as a before and an after, an onboarding and a success screen, and the person in the middle has nowhere to stand in it. I have spent a lot of time in the middle. I build for the middle.

Recovery became the reason for everything that followed. I work with people in crisis because I have been the person in crisis.

What does a decade of assessment do to the way you build?

It moves the hard part of the job to before the first line of code, and it changes what you think a system owes a person at the moment it fails them.

The decade, briefly. From 2016 I was a residential counselor at a treatment center: treatment plans across the six ASAM dimensions, a primary group of up to ten patients, and a weekly lecture to the entire patient population. I finished a BA in sociology in 2020 while working full weeks there, then a master's in clinical mental health counseling in 2022, and I hold an Oregon LPC and a CADC III. From 2021 to 2023 the job was assessment: high-risk, suicide and mental health assessments to determine need, plan and diagnosis. Alongside all of it, from 2019, I ran a private practice in trauma, addiction and serious mental illness, telehealth statewide, walking sessions and home visits, for people for whom healing has felt out of reach, and I built its brand, site and billing myself. Since 2023 I have worked in a county jail, doing high-risk and MAT assessments and running group and individual therapy.

Five things from those rooms are now load-bearing in the studio.

Intake is requirements gathering. I covered that in the wireframes post, so one sentence here: the first thing a person says is rarely the problem, and the first feature a client asks for is rarely the need. You ask, you repeat it back, and you do not start building until the formulation has been earned.

Assessment is debugging. An ASAM assessment is a discipline against the obvious answer: you gather in every dimension before you diagnose in any, because the presenting problem is the one the person could see, and the one that matters most may be two rows down. Debugging is the same discipline. Reproduce before you fix, read every layer before you blame one. When a photo pipeline went blank on me in August, I lost an hour suspecting the wrong layer for want of a number. The postmortem is written the way a clinical note is written, mechanism first and no blame, for the same reason: it is the only shape a fix can come from.

A safety plan is written for the hour the plan fails. Who you call, what you do, where you go, in that order, in words a person can read at two in the morning. Most software is designed worst at exactly that hour. The error state is written last, the empty state is an afterthought, and the page a visitor sees while a queue is behind is whatever the sort clause happened to produce. So the queue order in that postmortem is a product decision, one photo for every listing before forty for any listing, and a card is never blank while it waits. The motion rules in the design law come from the same place: a page that moves at you is spending attention the reader never offered, and the people I sat with for a decade were already at capacity.

The note is the evidence. Clinical documentation runs on a hard rule: if it is not in the note, it did not happen, not because anyone doubts you but because the note is the only thing that survives the shift. The engineering version is a line I keep repeating: check the artifact, not the receipt. A function's return value is a claim; the file is the evidence. A queue that reports done is a receipt. Nothing I ship is done until it is observed working in production, and the agents I run are held to the same rule.

The lecture is the copy. As a residential counselor I wrote and delivered a weekly lecture to the entire patient population. Nobody in that room had come to hear me, and everybody in it was carrying something heavier than my notes. You learn to say one thing, in order, in plain words, and to stop. Every copy rule on this site is a version of that.

Why build mental health software, of all things?

Because I have stood at both ends of it. For seven years I was the provider being searched for: a solo practice, statewide telehealth, my own site and my own billing. Before that I was the person in crisis, which is the other end. Both ends of a directory are people at capacity, one of them at two in the morning and the other between sessions, and neither of them is browsing.

ORCounselors is the result: Oregon's statewide mental health directory, 16,800 licensed providers indexed, more than 1,200 active profiles, a trained search assistant, and a native iOS app on the App Store. The front page leads with the questions a person actually has, which are not "who is best" but who is accepting clients, who takes OHP, who offers a sliding scale, and who will see them over telehealth. I talk with providers every day and change the intake flows from those conversations; the trust post is about what that took.

My about page says that software built by someone trained to listen comes out different: clearer flows, calmer interfaces, systems that respect the humans on both ends. I wrote that as a claim. The five rows above are the receipts.

What changed in 2026?

I closed the private practice in July to build full time. I still do clinical work: the county corrections role is current, and the assessments are the same ones. Ulric is the second Richers software company to call Oregon home, and I run every build with an agentic toolchain, which is the part of this story the other nine posts already tell.

The fruit-tree app is still unfinished. Every tree in the neighborhood on one map, the fruit free for anyone who wants it: it is still the best brief I have ever been handed.