Get ruthless about Swift concurrency
Actors and cancellation are easy to describe until one task outlives the screen.
First step: Build a small feed with cancellation, retries and tests.
Related reference →Personal notebook / Curiosities
Interview guideQuestions and curiosities I keep around
I keep a list of interesting problems and subjects because good ideas rarely show up at a convenient time. It ranges from mobile security and hardware to cooking, travel and getting outdoors. This is the personal side of the site, separate from my project portfolio.
The projects section covers systems I built; this collection is simply a set of topics that interest me. These are interests and possible future projects, not completed work or a record of my work history.
Browse the subjects51 ideas · 8 areas · An evolving list
Curious about the details
A small implementation or a concrete failure case usually tells me more than a broad claim about how a system should work.
Write down what matters
I write about implementation decisions and mistakes, not just the polished result. Sometimes the bug is the most useful part.
Get out occasionally
Hiking, cameras, recipes, dogs and exploring new places. A laptop is nice, but sometimes it can stay home.
iOS & Apple platforms
Profile a real app with Instruments
I want measurements, not a hunch about why scrolling stutters.
First step: Capture a trace, fix one bottleneck and compare before/after.
Related reference →Revisit App Attest threat boundaries
Device signals are useful; they do not magically authorize an API request.
First step: Map replay protection, challenges and server verification.
Related reference →Build a clean passkeys flow
Authentication should survive cancellation, migration and weird device states.
First step: Prototype enrollment, sign-in and recovery without hiding edge cases.
Related reference →Design an offline-first iOS app
A network request is not a storage strategy.
First step: Write a sync contract with conflict resolution and explicit retries.
Benchmark a tiny Core ML model
On-device inference is interesting when the memory and battery numbers behave.
First step: Measure cold start, peak memory and latency on actual hardware.
Related reference →Android & Kotlin
Stress-test Compose state handling
State ownership gets interesting as soon as the process is killed.
First step: Build a screen with process recreation and UI tests.
Related reference →Deepen Coroutines and Flow debugging
Cancellation and backpressure tend to show up at inconvenient times.
First step: Reproduce three race conditions and write deterministic tests.
Related reference →Review Play Integrity failure modes
Attestation is one input to risk, not a permission slip.
First step: Build a verification decision table for backend outcomes.
Related reference →Measure Android startup and jank
A smooth demo and a smooth cold start are two different things.
First step: Run baseline profiles and instrument a representative device.
Related reference →Ship a local-first Android sample
I want to know what happens after a week offline, not just a minute.
First step: Add a persistent queue, sync ordering and conflict tests.
Audit Android secure storage choices
Keys, backups, rooted devices and token lifetimes are part of the design.
First step: Write a small Keystore threat model with negative tests.
Related reference →Backend & distributed systems
Push idempotency to the ugly edge cases
Duplicate requests happen. A duplicate charge should not.
First step: Test simultaneous retries, timeouts and ambiguous results.
Related reference →Reproduce database isolation anomalies
Transaction isolation is easier to remember once it breaks a toy system.
First step: Write concurrent sessions showing phantom reads and write skew.
Related reference →Build a tiny tracing example
I want an answer to 'where did the request go?' without guessing.
First step: Trace one request through API, queue, and worker, including failures.
Related reference →Compare queues and delivery semantics
At-least-once delivery sounds fine until the consumer forgets idempotency.
First step: Implement backoff, deduplication and a dead-letter queue.
Break a Kubernetes deployment on purpose
Readiness, liveness and resource limits deserve a hands-on rehearsal.
First step: Kill a dependency and watch whether rollout and recovery behave.
Related reference →Revisit HTTP/2, TLS and DNS failure chains
A backend bug can live three layers below the API handler.
First step: Capture a trace and explain each hop from client to server.
Security & reverse engineering
Publish a malware behavior walkthrough
Execution chain, persistence, network behavior, mitigations. Keep it reproducible.
First step: Use a safely isolated sample or public analysis and cite the evidence.
Related reference →Deep-dive a mobile malware family
Android has enough IPC, permissions and background behavior to keep me busy.
First step: Map components, communications and data flow from public reports.
Related reference →Practice more binary reversing
I want to get faster at understanding a program without trusting its labels.
First step: Work through a legal challenge with Ghidra and LLDB.
Build an API authorization regression test
Object IDs should never be the authorization policy.
First step: Write a vulnerable endpoint, fix it and show regression tests.
Related reference →Implement cryptographic protocol tests
It's worth knowing exactly what fails when freshness or binding is missing.
First step: Model nonces, replay windows and key rotation in a toy protocol.
Related reference →Read more about red-team infrastructure
Designing tools is only half the story; secure operation matters too.
First step: Finish my current book, then summarize the engineering lessons.
Related reference →Trace a software supply-chain compromise
Signed packages and dependency graphs aren't the whole trust story.
First step: Diagram one incident from source to artifact to downstream impact.
Related reference →AI & machine learning
Build repeatable agent evaluations
If a prompt change helps two examples and breaks eight, I'd like to know.
First step: Add golden cases, refusal/permission checks and regression history.
Related reference →Harden tool execution boundaries
The model can ask. The server still has to say yes or no.
First step: Exercise cross-tenant, scope and approval failures.
Related reference →Prototype a small retrieval system
Retrieval quality is a system problem, not just an embedding problem.
First step: Compare chunking, recall and citation correctness on a test corpus.
Revisit ML fundamentals with code
A model should beat a simple baseline before it gets fancy.
First step: Implement linear regression, classification and evaluation from scratch.
Related reference →Measure inference latency and cost
P50 without P99 and a realistic traffic mix is an optimistic story.
First step: Benchmark batching, limits and failure behavior with synthetic requests.
Compare on-device AI on iOS and Android
Privacy, speed, power and model distribution all pull in different directions.
First step: Run the same small task on both platforms and log constraints.
Threat-model an agent with third-party tools
Prompt injection, exfiltration and overprivileged connectors are not theoretical.
First step: Draw trust boundaries and test malicious retrieved text.
Hardware & making
Build a small robot with real telemetry
Software behaves differently when a motor and battery are involved.
First step: Log sensor input, control decisions and failure states.
Design and assemble a simple PCB
I want to get closer to the electronics instead of stopping at the API.
First step: Build a sensor board, simulate it and test power draw.
Explore BLE security with real devices
Pairing, bonding and stale connections are great bug habitats.
First step: Instrument a lab device pair and record a reproducible trace.
Refine my portable remote-work setup
Power, connectivity and backups matter when the Wi-Fi disappears.
First step: Run an offline workday drill and note what fails.
Put together a compact home lab
Reproducing crashes and network failures is easier on my own equipment.
First step: Add isolated services, monitored power and a recovery plan.
Writing & career
Turn more fixes into honest engineering writeups
A useful case study explains the decision and the failure, not just the shiny result.
First step: Document one real bug with evidence, tradeoffs and tests.
Related reference →Make an open-source tool easy to reuse
A README is a user interface too.
First step: Add examples, reproducible tests and a concise threat model.
Related reference →Publish a practical mobile security lesson
Teaching something is a great way to discover what I don't understand yet.
First step: Take one small concept and build a runnable lab.
Related reference →Keep a working interview notebook
Real stories are better than memorized interview poetry.
First step: Write four accurate project stories with the evidence and tradeoffs.
Related reference →Build a small product people will pay for
Shipping is fun. Finding a problem worth paying for is a separate skill.
First step: Validate demand before designing the dashboard.
Contribute more to developer communities
Good technical feedback can save someone a week of debugging.
First step: Review a small PR or publish a troubleshooting guide.
Life outside the editor
Get properly good at a few favorite recipes
I'd rather make five dishes really well than bookmark another fifty.
First step: Keep notes, adjust one variable and cook them again.
Related reference →Spend time exploring Japan beyond the obvious stops
Food, transit, neighborhoods and a camera: pretty good research tools.
First step: Build a slow itinerary instead of a checklist sprint.
Explore more of Scandinavia
A bit of nature between debugging sessions sounds healthy.
First step: Pick one trail-focused trip and plan around the weather.
Find and hike more Bay Area trails
My laptop doesn't need to come on every walk.
First step: Choose a local trail and keep a small photo log.
Do something useful for animal rescue
A donation, volunteering, transport or a small bit of useful software.
First step: Find a local rescue with a specific, real need.
Take more photos worth keeping
I want to remember places instead of only my camera roll's file count.
First step: Publish a small set with locations and context.
Related reference →Explore another city on foot
Walking around a place teaches you things a search result won't.
First step: Pick a neighborhood, leave space in the itinerary and get lost responsibly.
Read more deeply and actually keep notes
Finishing a book is nice; remembering why it mattered is better.
First step: Add a sentence of my own after each finished book.
Related reference →