Software

Almost everyone carries a Visa or Mastercard and almost nobody can say what the company does. This explainer, written by an engineer with years in payments, starts with what card networks are not: They do not issue cards — issuing banks do They do not run checkouts or point of sale — processors do They do not onboard or underwrite merchants — merchant acquiring does They do not make cards or POS hardware What is left is the network role, which breaks into four jobs: ...

Jane Street published a challenge: here is a GDS layout file describing a custom chip, work out what it does, and extract the password hidden inside it. Jestoph spent a month on it and shipped the answer, (* TWO STARS *). The essay’s subtitle tells you what kind of writeup this is — “Why do I always do things the hard way?” The technical work is real: chip layouts are geometry, not code, so the only path in is to reconstruct a netlist from polygons and then reason about the resulting circuit. ...

Bryan Cantrill writes from the reader’s side of the page: too many people are putting their name to pieces that are clearly LLM-authored, and he has two pointed questions for them. Do you think readers cannot tell? Or do you think readers do not care? His answer to the first is that anyone who reads broadly can tell immediately — “the hand of the LLM is so clear it’s as if the writer’s intellectual fly is open.” The second question is where the argument gets teeth. ...

Glazer’s data team received CronosPro files (CroBank.dat, CroIndex.dat, CroStru.dat) that existing tooling could not parse — a proprietary desktop database format used across the post-Soviet world. The open-source cronodump converter failed on the schema file, so they had to recover an obfuscated schema before any records were readable. The write-up assumes no prior knowledge of the format and earns its depth. Key moves in the recovery: Narrow the target: only the small schema file was KOD-encoded; the huge record file was merely compressed. Crack the schema and the ordinary parser handles the rest. KOD protection is a position-dependent byte substitution (plaintext = KOD[cipher] − position − record number, mod 256). Being off by one byte corrupts everything after it. Reconstruction became an assignment problem: a KOD table must be a true 256-entry permutation, so they scored each candidate mapping against known-good dumps and solved globally with the Hungarian algorithm — not per-byte greedy picks. Validate structurally, not visually: record markers, length-prefixed names, known keys like Bank/BankId/BankName, consistent table references. “Readable output alone is weak evidence.” Two parser bugs surfaced: a 12-byte Cronos v4 extent header was fed into the KOD decoder (shifting every byte position), and documented text types were being exported as hex instead of Windows-1251. The subtlest trap: hidden internal fields. Visible field definitions mapped to stored positions 2, 4, 7 — not 1, 2, 3 — so a CSV could look valid while every value sat under the wrong header. The key lesson is that a decoding failure does not always mean a bad key — sometimes the right decoder runs at the wrong boundary. And a CSV with readable values under wrong headers is worse than an obvious error, because it looks valid while being semantically corrupted. ...

A short personal essay from an anonymous blog (strong HN reception) that splits programmers into two types: people who write code to build products and make money, and people who write code because they cannot help it. The author places himself firmly in the first camp — he prefers creating to coding and happily delegates when possible — then makes an argument about the second. The essay’s core claim: For “true programmers,” the process is the point: solving, designing, debugging, understanding the whole system. Income and output are secondary. So the “AI will replace programmers” claim is a category error for them — even a fully autonomous AI would not remove their desire or ability to write code by hand. The author’s parallel is writing: he refuses AI for prose because the thinking that happens during writing is the valuable part, and AI output feels soulless. Coders who treat code as art feel the same way about code. It is a useful counterweight to productivity-centric AI discourse — a reminder that a meaningful slice of the profession optimizes for the experience of the work itself, not just the shipped result. Whether or not you share the romanticism, the question it poses is worth sitting with: if code could be written entirely by agents, who would still choose to write it, and why? ...

Michael Stapelberg finally achieved a years-long goal for Debian Code Search: deleting its last cgo dependency. For seven years the search engine called the TurboPFor C library for integer compression; Go 1.26’s new experimental simd/archsimd package finally made AVX-512-class SIMD reachable from plain Go, so he reimplemented the codec natively. The post is a model performance-engineering retrospective: Audit actual usage before optimizing — the decoder looked like the hot spot, but the query path tolerated 10-100ms of regression; reducing allocations and specializing per bit width was enough there The encoder (used for partial indexing and full-index merges) was where raw speed mattered — a native Go version hit 76% of C in a few days SIMD kernels plus bit-width specialization beat the old cgo path in 2-3 commits A positional-popcount technique for block scanning delivered another 2x Apples-to-apples against clang-compiled C, Go is about 1.4x slower — but versus what DCS actually shipped, pure Go matched or exceeded it Value decoding runs at 7 instructions per cycle on hardware capped at 8 He also catalogues the Go compiler costs with real nuance: bounds checks cost performance but stay on for safety, mid-stack inlining NOPs slow dispatch-bound functions, and you cannot target a specific microarchitecture — so Intel-era POPCNT workarounds tax AMD Zen users too. ...

Austin Z. Henley’s weekend challenge: a Python interpreter in 1024 bytes of C, “no macro shenanigans or library tomfoolery.” His first attempt at 512 bytes only produced a calculator, so he asked a sharper question — what subset of Python can fit that still looks like Python, with defs, colons, and indentation? The answer skips CPython’s tokenize → AST → bytecode pipeline entirely: State is a handful of globals: a source buffer, a 256-entry symbol table, a few position pointers Recursive descent parses and executes expressions at the same time — no intermediate representation exists The C call stack handles indentation blocks: a block function returns when indentation drops below its minimum Loops and functions work by time travel — they record a source position, then jump back and re-parse the code each iteration or call It trusts the programmer completely: no error handling, keywords skipped by counting characters, single-letter variable names so lookup is a direct array index Feature set that survived: integer math with precedence, comparisons, if/else, while and for-range loops with else, argument-less functions (even recursion), print, comments Minification took the readable 4800+ bytes down to exactly 1024 — implicit-int C89, zero-initialized globals, ASCII values instead of char literals, ternary and comma operators, recursion over loops. ...

Rachel Laycock, CTO at Thoughtworks, takes the other side of the “what is code review even for” debate — a written response to DX’s Brian Houck after the two disagreed on a Code Remix panel. Her argument isn’t that AI broke code review. It’s that review was quietly doing five jobs at once, and the AI code-volume spike made that unsustainable. The overloaded code review: Review carried quality gate, security check, architecture review, mentoring, knowledge-sharing, and ownership — all at once Meta’s human-landed diffs grew 106% in a year and median PR size is up 64% — no human review queue absorbs that Her fix is not “review faster”; it’s stop waiting until review to have the important conversations Shift the judgment left: ...

Dan Luu on why he sees hundreds to thousands of bugs per week while most people see none — not because he uses computers differently, but because everyone else is hitting the same bugs and not noticing. The mechanism is human: we are extremely good at ignoring the negatives in things we’re fans of, and that blindness is strongest about our own work. How bug blindness works: Most people hit the same bugs and don’t notice them — “computer literacy” is really a library of non-conscious workaround habits (the Google Docs title-overwrite dance, the WiFi-off-before-login ritual at Microsoft) Dogfooding mostly fails: programmers are expert bug-workarounders, so they literally don’t perceive the issues their habits exist to avoid Teams ship confidently broken: internal comments say “great, it works well” while the product only works with non-intuitive workarounds — the Blackboard employee who believed users loved the most-hated software in education Fans rationalize away evidence everywhere: Volvo forums on reliability, search-engine fans defending spam-filled results, Discourse engineers whose code cheated LCP metrics The trainable part: ...

Dan Luu’s running thesis: the cost of formerly-specialized performance work has dropped by orders of magnitude. Optimizations that used to require a rare expert — JIT compilers, custom regex engines, workload-specific low-level code — can now be done by anyone who can type a few sentences to an agent. The honest title is the argument: slow software is a choice, not a constraint. Evidence from the post: The FRE regex engine: an agent loop built it; adding an AOT native-code compiler that cuts over mid-search gave 2–4x on long ripgrep queries and ~7% on representative holdout queries — a few minutes of human time Jamie Brandon vs. Claude on Anthropic’s performance takehome: the model’s optimizations were “crazy shit that I would never try unless I was working on this for weeks” His Azul game AI became the strongest in the world in a fraction of the time of the second-strongest — ~100 Elo per doubling of speed, with LLM-written multi-threading doing most of the heavy lifting Workload-specific optimization is now launch-and-wait: a two-minute agent run gave ~2% over ripgrep on his own query holdout, still improving The caveats that keep it honest: ...

Superwall’s Joseph Choi talks to Asya Polony, CPO of Welltory — the Apple Watch app that reads physiological signals to show where your energy drains. 51 minutes, $18M ARR, ~18M downloads, and a full walkthrough of her team’s onboarding deck. The six-ingredient pitch formula The framework Asya uses for onboarding (and says works for pitching anything): ...

Cloudflare’s Rust DNS platform (Big Pineapple) holds over 250 billion cache entries at any given time — so wasting a single byte per entry costs 250 GB of RAM across the fleet. Five successive changes to how entries are stored cut the per-entry footprint by more than half and freed roughly 100 terabytes, equivalent to the RAM in 130 of their Gen 13 servers. The optimizations, each small and obvious in retrospect: ...

What if the file you chmod +x and run were itself a database? Farid Zakaria’s SELF prototype (Structured Executable & Linkable Format) replaces ELF with SQLite — the executable is a real SQLite file, and every tool that reads ELF reduces to a SQL query. The core argument: ELF is already a database that refuses to admit it. .strtab is string interning, .gnu.hash is a hand-rolled index, st_name offsets are foreign keys done by hand, and strip is a DELETE + VACUUM Every consumer — kernel, ld.so, binutils, LIEF — re-implements the same parser against a terse, schema-less format designed for 1970s disk constraints How SELF works: ...

Janet A. Carr’s first-ever sponsored stream (partnered with Render) is a 6:53:57 build-in-public marathon: she and “a friendly clanker” (Claude Code) build an AI auto-clipper that turns a VOD into topic-matched clips, and against all live-stream odds the thing works and gets deployed to Render before the stream ends. The description teases “45 minutes of clip farming and time wasting to give haters some ammo before actually getting into the coding.” ...

Writing code is translating an idea into instructions a computer can execute. Building software is deciding which instructions should exist, which constraints matter, which tradeoffs are acceptable, and how the system evolves without collapsing under its own weight. AI is extraordinarily good at the first problem — the second is where software engineering begins. Code was never the hard part The questions that actually decide a system — synchronous or queued, exactly-once or at-least-once, tolerance for eventual consistency, retry counts, event ordering, three-hour consumer outages, traffic today vs two years from now — have very little to do with syntax. Language choice matters for fluency, performance, safety, maintainability, and tooling, but it doesn’t answer the fundamental questions. The hard part is choosing the architecture that represents the right set of compromises. ...

Anik Sikder’s essay starts where architecture actually starts: a founder says “we need an ERP,” and the first questions are about responsibilities, not frameworks. The thesis running through the whole piece — organize around meaningful business capabilities before technical abstractions, and give every component a reason to exist. Capabilities, boundaries, ownership Map business capabilities first (identity, inventory, sales, billing, reporting) so the code structure starts reflecting the business — someone joining six months later can read the product from the layout. A boundary is not a folder; it defines ownership. Poorly isolated responsibilities turn a change to Inventory into a chain of breakages across Sales and Reporting. Layers (API → application service → domain rules → persistence → database) exist for clear ownership, not for their own sake — the API layer shouldn’t become the entire business engine. Follow the request, not the diagram Walk a real request (create order) through the system: authenticate, authorize, validate, apply domain rules, commit the transaction, emit the event. “If you cannot explain why a component exists in the request journey, question whether you need that component.” Don’t turn everything into a service — hundreds of abstractions are not architecture. Ask what business operation each component represents. Data, transactions, and async The database is not “just storage”: model inventory movements, not just a quantity, so the system can answer both “how much do we have?” and “why do we have this amount?” Operations that must succeed or fail together share a transactional boundary; emails, PDFs, and analytics don’t belong inside it. Queues and workers follow from “which work should not block the user’s request?” — not from “let’s install RabbitMQ.” Security and multi-tenancy Authentication asks who you are; authorization asks what you’re allowed to do — different architectural concerns. Tenant isolation is an architectural security boundary: “can this user, inside this organization, perform this action on this resource?” The database schema should reinforce it. Microservices are earned, not assumed A five-developer, ten-customer company that starts with a service mesh has built a distributed system before it had a distributed problem. Start with a modular monolith: boundaries stay explicit while deployment stays simple. Extract one capability (e.g., reporting) only when it becomes a real bottleneck. Five questions before adding any component: what problem are we solving, who owns this, does it need to happen immediately, what happens as the system grows, and what does it cost operationally? The takeaway: good architecture is an evolution path, not a perfect day-one diagram — complexity should be earned by the problem. Sikder closes with a production checklist spanning business, data, security, performance, reliability, and observability: if you can’t answer those questions, the architecture probably isn’t finished.

An essay from The Phoenix Architecture argues that architectural knowledge lived inside the implementation for decades because the implementation was expensive to reproduce. That expense is disappearing — and as it goes, we find out how much of what we called “architecture” was really the cost of change wearing a disguise. Cheap code was supposed to make architecture matter less. The essay’s case is that it’s doing the opposite: as implementation gets cheap, architecture becomes both more important and, for the first time, visible. ...

A senior engineer asked Lalit Maganti (Google, Perfetto) how to find problems worth working on while making the jump to staff. The answer isn’t blocking calendar time to “think strategically” at a blank page — it’s acting like a sponge: absorbing the stream of day-to-day noise until connections appear between problems that initially seemed unrelated. Absorb problems, not requests People constantly talk about what’s hard — meetings, chat threads, email. When something overlaps your area, pull on the thread: “If X existed, would that solve it?” Users ask for a particular solution, not their root problem. Keep digging until you understand what they’re actually trying to accomplish and why existing products don’t work. Ambient listening suits introverts — no speculative meetings needed; the information is already flowing around you. When a problem seems worth exploring, see it firsthand: sit with the team, walk through workflows, reproduce the bugs yourself. That separates what they need from what they asked for. Seek out people who see more of the org — owners of critical systems, cross-team folks — and ask what interesting problems they’ve noticed. They’ve often already connected the dots. Let problems accumulate Moving too fast burns you: build a feature a vocal team wanted, watch them barely use it. Enthusiasm in the moment isn’t the same as importance. Waiting is a superpower. The same problem surfacing in different teams raises its priority; surface-different problems can share a shape; sometimes the requesting team didn’t care much at all. Make a mental note (or write it down, whatever works) and revisit if the problem comes up again — keep unresolved problems around long enough for evidence to accumulate. Find the common shape Perfetto example: over two years, teams kept requesting small UI additions — pinned tracks, zoom presets, custom aggregations. None of them wanted their specific feature; each wanted to personalize Perfetto without imposing on everyone else. The underlying need was extensibility → shipped as macros + extension servers. Best untangling happens on long, aimless walks — not by forcing solutions at a desk. Caution: a common shape is only a hypothesis; elegance is not evidence. His transparent-caching idea for Perfetto traces collapsed on scrutiny — the two problems wanted genuinely different solutions, so he split the design in two. Pressure-test before building Low-risk and useful → act immediately. Unsure → throwaway prototype. Big and convinced → full commitment, including the hard yards of building support. You’re also convincing yourself: be willing to stop, or park an idea until it becomes an org priority. You don’t have to be the builder — shaping the right problem has impact even when someone else implements it. Solving useful problems finds the next one People remember genuine interest and help; they start coming to you earlier and bring you into wider conversations. Success builds trust through long-term stewardship — eventually your judgment carries weight without you owning every project. Staff engineering isn’t replacing technical work with meetings and coordination; conversations are inputs to what you build, not the end result. The takeaway: finding problems worth solving isn’t separate from the job. It comes from staying engaged with people’s work long enough to see what no single request can show you.

Sean Goedecke argues that the skill-atrophy case against AI-assisted development is a bad argument — even granting its premises. His claim: until around 2024, the best way to learn software engineering was simply doing it, and that lucky coincidence let people parlay a coding hobby into a lucrative lifetime career. That was never an immutable fact about the profession. The essay’s structure: The anti-AI argument runs: AI use means less learning, skills atrophy, therefore don’t use AI. Goedecke grants the first premise and says the conclusion still does not follow If AI provides enough short-term benefit, engineers may be obliged to use it anyway — the same way construction workers are obliged to lift heavy objects, because that is what they are paid to do If models are good enough, hand-coding purists get outcompeted by engineers willing to trade long-term cognitive ability for a short-term lucrative career Pro sports careers max out around fifteen years, and the tragedy is the athlete who never plans for the end. Software engineering may be entering the same territory His edit-note addendum: once you stop writing code by hand, your ability to understand the codebase at large may atrophy too — and the rate of change is high enough that nobody knows what the field looks like in a decade This is not an argument that AI is good. It is an argument about career planning: the assumption that loving the work naturally compounds into a lifelong career was contingent, not guaranteed — and it is worth planning as if it might not hold.

If you run scraping or content-gathering from a datacenter IP, you will eventually hit the wall: Cloudflare’s “Just a moment…” interstitial, a bot-detection 403, or a paywall that truncates the article after the first paragraph. The naive fix — a browser user-agent, retries, a different tool — rarely works. What does work is a ladder of fallbacks, cheapest first, where each rung is a different class of access rather than a retry of the same one. ...