Building production tools — codegen, transpilers, chess software — and the trade-offs each one exposed.
4 published entries
These series give this subject an intentional reading order.
Notes from building production tools: the trade-offs, constraints, and questions each project exposed.
See the 4-part reading order →When a binary does something interesting, you usually have three options: reverse it manually, call it as a black box through P/Invoke, or emulate it instruction-by-instruction with something like Unicorn Engine.
Alicorn started with a question I couldn’t stop asking: what if you could take raw x64 machine code and turn it into readable, editable C#?
I needed to merge hundreds of Lichess PGN files into a single database for opening preparation. The existing tools either required Python dependencies, discarded game metadata, or merged games into variation trees rather than concatenating them cleanly. I wanted a standalone CLI that takes a folder of .pgn files and produces one merge.pgn — fast, memory-efficient, and correct.
ZaString started with a frustration. I was working on a high-throughput system in C#, and every profiler run showed the same thing: strings everywhere. Allocations piling up. The garbage collector working overtime. Not because the code was wrong, but because strings in C# are immutable and every operation creates a new one.