RF engineering taught me that most of the job is repetitive work waiting to be automated.
Now I build the systems that do the repeating.
|
A browser arcade game. No install, no loading screen, no tutorial. Just reflexes and the compulsion to try once more. 
|
Everything else, written up with the reasoning behind it: what the problem was, what I tried, what broke. 
|
Bench side
What working with instruments taught me about writing software
Failure is physical, so you stop trusting yourself. A loose SMA connector costs you three hours and a data set. You learn to verify before you assume, and to build the check into the process instead of into your memory.
Every measurement needs a units label. Ambiguity in a lab is expensive in a way ambiguity in a codebase only eventually is. I name things carefully because I've been burned by dBm versus dBmV.
The interface is the product. Nobody cares how elegant the sweep routine is if the operator can't read the output. Most of my frontend instinct comes from watching smart people struggle with tools built by engineers who never watched anyone use them.
Automate the boring part, then automate the part that checks the boring part.
What I'm working on now
| Studying | CS degree, currently deep in systems and data structures |
| Building | measurement pipelines and the web layers that make them readable |
| Learning | real time data handling, clean API design, and getting better at C |
| Curious about | embedded Rust, WebSerial, and browser based instrument control |
Open to internships and collaborations, especially anything where hardware and software meet.
