About
How I approach difficult technical questions, and the habits that shape the work.
The practice
I define a technical question, build the software or experiment needed to test it, compare the result against simpler baselines and falsification controls, and document what the evidence supports—including when the answer is negative.
That process has taken me across climate forecasting, financial time series, signal processing, synthetic-aperture radar, and the built environment. The domains change; the working method is consistent: explicit assumptions, reproducible implementation, controlled evaluation, and clear technical writing.
I choose projects out of curiosity and finish them with working code, documented methods, or a clear written result.
Working habits
Each habit below links to a study where I used it.
I write down the result that would answer the question before I start building around it.
In the Signal-Scale Scan, I fixed the timeframes, horizons, targets, and decision rules before running the comparison.
Read the Signal-Scale ScanI compare a new method with a simple alternative before deciding whether the added complexity helped.
In WaveGAN-2, matched linear and convolutional baselines beat the neural wavelet variants at every horizon.
Read the WaveGAN-2 studyI put the assumptions that affect a result next to the result itself.
The ENSO series charter records the shared metrics and the cases that should not be compared directly.
Read the ENSO series charterI publish useful negative findings and partial improvements without recasting them as wins.
The Frozen-Backbone Head Lab found volatility information but no durable directional edge.
Read the Frozen-Backbone Head Lab