How I Work

Personal stake first. Then whatever tool the problem needs.

Picking problems

Given an open-ended choice, I pick the problem I'm personally invested in over the one that looks best on paper. My turbulence project is the clearest example: I could have modeled wind flow through a simplified city, which maps directly onto a real problem companies like Amazon are working on for delivery drones. I chose to model a kiteboarding site instead — a problem that required essentially the same skills, but one where I already had firsthand experience with the thing I was trying to explain, and where I actually cared whether the final result was clean and complete. The stake is what gets the extra effort out of me, not the resume value.

Starting from zero

Where I start depends on what kind of problem it is. For a design problem — like the desiccant wheel — I start with research: what already exists, how competitors solve it, what's actually replicable at a mechanical-engineering-student scale without needing industrial chemicals or equipment. From there it's sketching, prototyping, and solving problems as they come up until you reach a finished design.

For a problem that's really about understanding a phenomenon — like the wind behavior at Whidbey Island — I don't start with a literature review. I start with what I've already observed firsthand and work outward from there, using the research and the tools to explain something I already had a real question about.

When something breaks

I don't have one fixed process for this — it's different every time — but the pattern that holds across projects is that fixing the failure means learning something new, not just debugging harder with what I already know.

On the desiccant wheel CFD, the early failures were about the CAD itself — building a model that would actually mesh cleanly for CFD, and then making sure my assumptions about the exit boundary conditions (treating the outflow as fully developed) didn't create artificial backflow that would have made the results meaningless.
On the linkage's control system, the wiring issues were normal troubleshooting. The PID tuning was the real problem, and it wasn't a code problem — the joint bolts loosened slightly every run, which changed the friction and threw off an already finicky tune. Under a real deadline, without a torque wrench to give us a consistent spec, the honest fix wasn't clean: tighten, run, watch the score, adjust.
On the turbulence simulation, I never actually got the LES code to converge. Getting anywhere on that meant learning the simulation code well enough to look at the output and diagnose what was actually going wrong — not just re-running it and hoping.

Why design, not manufacturing

I have plenty of hands-on machining experience, and I'd take it over not having it. But on the build side, for a lot of complex parts you're just executing the part in front of you — understanding how it fits into the whole system helps, but it isn't always the primary thing driving how you machine it. Design is the opposite: you're constantly solving problems at the system level rather than the part level. That's the side I want to be on.

draft — pending review