About

Hello — I'm Ben

I'm a mechanical engineer. I build test hardware, run the measurements, and then go looking for the reasons they might be wrong. It's a slower way to reach a result and a much better way to keep it.

01 The short version

The through-line

I came to the University of Washington in 2020 for a mechanical engineering degree and stayed through a master's and into a doctorate. Along the way I have designed and machined test hardware, integrated high-voltage systems, built acquisition and analysis pipelines, taught thermodynamics and fluid mechanics at undergraduate and graduate level, advised a senior capstone team, and spent nine months coordinating customer-sponsored R&D for aerospace and defence organisations.

The technical thread through most of it is plasma actuators — surfaces that move air using nothing but an electric field, with no moving parts at all. But the transferable part isn't the plasma. It's that this is an unforgiving thing to measure: kilovolt drive noise sitting on top of forces counted in micronewtons, produced by a discharge that changes inside a single AC cycle. You can't argue your way to a result. You either build an instrument you can defend, or you generate numbers that mean nothing and don't find out for a year.

So the habit I've ended up with is refusing to trust a measurement until it has earned it — checking the instrument against itself, and being willing to discover that the convenient answer was an artefact. That travels to unfamiliar problems far better than any particular piece of physics does.

The other half I care about is the write-up. A result nobody outside the room can act on isn't finished.

Benjamin Price in a suit outside a Gothic stone building on the University of Washington campus.

02 How I work

Four things I do on every project

i

Measure the instrument before the experiment

Where it matters, measure the same quantity two independent ways and find out where they disagree. Systematic error doesn't announce itself — it just makes the data look calm.

ii

Automate before the campaign, not after

Manual collection is slow, it hides operator variance, and it quietly decides which parameter sweeps you can afford to run. Automating first changes what experiments are possible at all.

iii

Write for the person who wasn't there

Reports get read by people who weren't in the lab and won't ask a follow-up question. If the method, the caveats and the recommendation aren't legible on the page, the work didn't land.

iv

Be explicit about what the data can't tell you

The boundary of a result is part of the result. Saying plainly where the measurement stops being trustworthy is what makes the rest of it usable by somebody else.

03 In the lab

The people and the hardware

Research is a team sport with expensive equipment. Some of the group, some of the conferences, and some of the things we point high voltage at.

04 Outside

Outside the lab

Washington is an unreasonably good place to not be indoors, and I take advantage of it — hiking and backpacking, mostly, from Cascade day climbs to the coast.

The other habit is harder to shake: I will go a long way out of my way to look at a good piece of engineering. Turbofans, launch vehicles, anything sectioned so you can see how it works. It is the same instinct that got me into the lab in the first place.

05 Contact

Get in touch

Questions about the research, an experiment you are trying to make behave, or a role you think I would suit — all welcome.

Email

benprice@uw.edu

LinkedIn

/in/price-ben ↗

GitHub

@benprice2310 ↗

Google Scholar

Publications ↗

ORCID

0000-0002-2335-6814 ↗

Based in

Seattle, Washington

Affiliation

UW Mechanical Engineering

Status

Ph.D. expected 2027