schmelczer.dev
RSS feed

About

A few sentences about the two moves I keep reaching for, and the posts that show them in different shapes.

I'm Andras. I write software for a living, and have done so for about six years. MSc in CS. The first non-trivial thing I finished was a Raspberry Pi music visualiser driving LED strips through MOSFETs in 2016, and I've been chasing that same feeling ever since: pick something I can't yet do, then finish it.

Two patterns show up in almost everything here. First, the hard constraint usually picks the data structure: an 8-bit ALU, a mobile GPU, a single static HTML file, a cross-language ABI, no edit history. Second, once the data structure is right, the API shrinks to something I can defend in one paragraph. When I get those two right I tend to like the result years later. When I don't, I say so in the writeup.

Quick Facts

Lives in
Europe.
Studied
MSc Computer Science. BSc thesis on SDF-2D, MSc thesis on GreatAI; both have writeups below.
Languages I'm fastest in
TypeScript, Python, Rust. C or Rust when bytes matter.
Email
andras@schmelczer.dev
Elsewhere
CV GitHub LinkedIn

Selected writeups

Finished projects where a hard constraint did most of the design work.

All articles

  1. A Python Framework Where Doing the Right Thing Is the Default

    Policy expressed as a small API.

  2. A 3-Way Text Merger That Never Shows Conflict Markers

    A merge design shaped by no history and three editors.

  3. A 2D Ray Tracer for the Browser, Tuned for the Phone in Your Pocket

    Mobile GPU limits drive the rendering architecture.

  4. Syncing State with an Immutable Trie

    Immutable tries make sync cheap and explicit.

  5. Two Graphs Are Simpler Than One: A Cooling System Simulator

    Separate graph passes keep simulation logic readable.

A few things I believe

  • Most "interesting algorithm" problems are actually data-structure problems wearing a costume. Pick the structure that makes the comparison, the query, or the merge trivial, and the algorithm fits in a screen.
  • A library you can explain in one paragraph beats a framework you have to teach. I'll take five lines of WGSL I can read over one beautiful 300-line kernel.
  • The cost of a project is whether I'll still trust it in three years. The ones I trust are the ones with a tiny surface and a boring centre.
  • I like working at the seams: firmware meeting a render loop, a Rust core crossing wasm-bindgen and pyo3, a client and server agreeing on what "next state" means. That's where the design work actually is.
  • Caveat: the writeups here are biased toward things that worked. The dead prototypes don't have URLs and I should probably write up one of them honestly sometime.