The kind of work where reading the spec is the first step and the second step is writing tests against it. Codecs, real-time media, P2P networking, and the deep parts of the stack most teams would rather not touch.
Algorithms, audio and video processing, codec work, P2P networking, and other engineering-depth projects where performance and correctness matter.
The kind of work where reading the spec is the first step. Recent examples include MP3 decompression and a peer-to-peer voice-call stack.
Go, C, Swift, low-level TypeScript, WebRTC, audio and video codecs, profiling, fuzz testing.
Yes. RFCs, codec specs, and protocol specs are a regular shape of work. The first deliverable is usually a test suite derived from the spec, then the implementation that passes it.
Measure first, optimize second, and only after the optimization is shown to matter on a realistic workload. Microbenchmarks are useful for ruling out, not in.
Where it's worth the cost. Parsers, codecs, and protocol code benefit most. Fuzzing pairs well with characterization tests to catch the inputs you didn't think of.
Tell me what you're trying to do. I'll let you know honestly whether I'm a good fit.
Get in touch