Evan Czaplicki — the creator of Elm — spent years trying to bring “languages like Elm” to SQL, and the result is Acadia, now in public alpha. The thesis: the type mismatch between expressive languages and databases is the root cause of mountains of error-prone glue code, and a compiler can verify schemas, queries, and migrations the way it verifies the rest of the program. Four goals drove the design: ...
GitHub CTO Vlad Fedorov’s postmortem for the August 17 outage — 7 hours 47 minutes that disrupted github.com, authentication, Actions, APIs, pull requests, issues, and Copilot. The headline finding: neither this incident nor the August 6 Actions failure was caused by a code or configuration change. Both were capacity failures. What happened: Traffic hit a new peak and a critical Central US data center component failed to scale with it; the capacity pressure spread and caused authentication failures that cascaded across services. Recovery needed coordinated rerouting, isolation, and staged restoration — and a client-side retry loop in Copilot services added traffic during recovery and had to be mitigated first. The scale context: monthly commits grew from 1.4 billion to 2.9 billion since April, alongside roughly 130M merged PRs and 24M new repositories per month. The work ahead: ...
A systematic literature review published in MDPI’s Software journal (April 2026) synthesizes 42 studies on decision-making in agile software engineering. Hannes Salin and Yves Rybarczyk (Dalarna University) screened 1,391 papers from 2014–2024 to map how decisions are modeled, made, and studied across the agile lifecycle. The headline finding: research on agile decision-making is heavily lopsided. Planning is the most-studied stage (34 studies) with the greatest diversity of decision models; requirements follows with 20 Analytical (15) and hybrid (11) models dominate; intuitive and consensus models are barely represented Coding, testing, and release/operations are “significantly underrepresented” Developers are the decision actors in over 78% of studies; managers appear mainly as escalation authorities — no reviewed study examines managers as agile decision-makers in their own right Group decisions dominate; individual autonomous decisions are under-theorized The authors argue this is partly a research accessibility bias: planning ceremonies are formalized, artifact-driven, and observable, while coding and testing decisions are tacit, rapid, and embedded in the work — so they rarely get documented or studied. In socio-technical terms, agile’s “social subsystem” (collaboration, ceremonies) is well supported while its “technical subsystem” (implementation-time judgment) has no standardized toolkit. ...
Swizec Teller runs a team shipping 2,900 pull requests per quarter. The bottleneck isn’t writing code — it’s validating it. AI code-review bots (Cursor’s BugBot, custom Claude review skills) helped once but grew into a cost and attention problem: slow, pedantic, expensive, and paradoxically adding review burden by requiring humans to review both the code and the AI’s commentary. Swizec’s solution: custom linters generated from design docs and style guides, using an LLM once to write the rule rather than running it on every PR. ...
Shivansh Inamdar builds software for autonomous warehouse robots at Nimble Robotics. When a robot bug can bring down a section of a fulfillment center, the failure path stops being an afterthought. His essay distills three hard-won reliability lessons that apply to any software system — web apps, mobile apps, distributed services — but are rarely taught in practice. Design for failure, not around it. In robotics, sensors fail, items shift, grasps slip. A bag that sags in the wrong way can cascade into a warehouse-wide outage. Build to detect failure, contain it, and recover — don’t just optimize the happy path and tack on error handling later. “At scale,” Inamdar writes, “the failure path is the product experience.” ...
Mark Seemann has long argued against object-relational mappers. Here he makes a sharper case: if LLMs write code, the ORM’s strongest justification — reducing boilerplate — falls away. Why keep wrestling with a temperamental implicit API when you could ask an LLM to write fine-tuned parameterized SQL directly? ORMs bring their own pitfalls: anti-patterns, idioms to follow, particular APIs to avoid, specific parameter values to explicitly pass This is ironic — ORMs promised freedom from SQL details, yet experts must know query efficiency intimately to use the ORM correctly The boilerplate argument evaporates when an LLM can generate all the mapping and query code for either approach Seemann’s proposal: write parameterized SQL directly, ask an LLM to produce it — and remind it to avoid SQL injection Seemann’s point is that the LLM disrupts the ORM’s value proposition. The old tradeoff — write ORM boilerplate vs write SQL boilerplate — is dead if the LLM writes either one equally well. The ORM’s query-tuning surface area becomes pure liability. The default shifts toward plain SQL for anything beyond basic CRUD, with the LLM handling the mapping and boilerplate that ORMs were supposed to solve.
Senko Rašić pushes back on the AI-era dismissal that “LLMs may be good at coding, but software was never the hard part.” He argues it insults programmers, then turns the same skeptical lens on the opposite cliché — that deciding what to build is the real difficulty. If coding is easy, why were programmers in high demand and well paid even before ZIRP? Why the 10x rockstar hunts, leetcode gauntlets, burnout, and doorstoppers like Clean Code, The Pragmatic Programmer, and The Art of Computer Programming? “If coding is easy, why is software so damn buggy?” ...
Search-relevance engineer Doug Turnbull’s counterintuitive trick for LLM classification into a huge fixed taxonomy (the Wayfair WANDS dataset has hundreds of legal category paths like Furniture / Living Room Furniture / Coffee Tables & End Tables / Coffee Tables). The problem Constraining an LLM to a legal vocabulary via structured outputs means shipping a giant Literal[...] of ~500 values in a Pydantic schema with every call — expensive, and there’s an upper limit on what you can send. Classic approach works, but doesn’t scale cheaply with small/dumb models. The trick Don’t constrain — hallucinate. Ask a cheap LLM to invent plausible, never-seen classifications for the query (brown coffee table → something made-up like Furniture / Living Room / Tables / Coffee). Resolve with embeddings. Precompute an in-memory MiniLM embedding for every real classification, embed the fake one, and dot-product to find the nearest real category — which lands exactly on Furniture / Living Room Furniture / Coffee Tables & End Tables / Coffee Tables. Why it’s cheap: hallucination tasks run on small/dumb models, and the schema never goes over the wire. Code: a Colab notebook plus cheat_at_search/enrich/vocabulary.py on GitHub.
Aaron Boodman (CEO of Rocicorp, creator of Replicache, ex-Google Chrome) explains durable objects in a three-tweet thread: “The name is awful but I can explain it to you. It’s a really cool and unique architectural primitive.” The pitch Think serverless functions, but stateful. A serverless function is a stateless JS program uploaded to Vercel: request in, result out, program destroyed. A durable object is the same thing except the external interface is a class, not a function — and Cloudflare keeps the instance running. Same URL, same object. If another request hits the same URL, CF routes it to the same running program and the same JS object in memory. You keep state across invocations. “That’s it, that’s the whole pitch.” Cheap, so you can have zillions. Low-power programs (max RAM ~1GB), cheap to run — a natural fit for chatrooms, multiplayer games, and similar stateful problems. Why it’s not just functions with global state The difference is the guarantees: ...
Philippe Xanthopoulos ran offshore delivery at a scale of ~240,000 development hours per year. His signature sat at the bottom of software budgets. So when he says what software costs, he says it as a witness — not a theorist. Over weeks this year, working alone with two AI collaborators under written contracts, he shipped a production decision engine whose quality metrics beat anything he ever saw come out of a team. The engine makes technology strategy auditable using mixed-integer optimization — complete search with optimality certificates, no heuristics, every shadow price printed as a Lagrange multiplier wearing its business name. ...
Gergely Orosz writes an unusually personal piece: he is coming to terms with AI writing most of his shipped production code — faster, with similar results, and better than him in less-familiar languages. The essay is honest about what that costs, not just what it saves. It is drawn from his longer analysis “When AI writes almost all code, what happens to software engineering?” The craft is the loss: years of learning C, decoding complex codebases, debugging — all validated by the simple fact of writing code that works. AI devalues that validation The zone was identity: some of his best memories of building software are being locked in, compiling, running, and seeing “YES, it worked” It was never pure joy: the focus demands were real, including time-estimate conflicts — time passes differently when you’re deep in a hard problem The open question: does satisfaction migrate up the stack, to thinking about higher-level problems while instructing more complex code to be written? The piece refuses both lazy framings — “AI makes engineers obsolete” and “AI is just a better tool.” It treats the emotional accounting seriously and ends without a tidy resolution: “Yes, AI is convenient, but there’s also a loss.”
The Pragmatic Engineer deepdive into Optiver — a 40-year-old Amsterdam prop trading firm with ~950 engineers, 2,200 employees, and €4.5B in trading income — reveals an engineering environment with constraints most tech companies never face. No external customers (the business itself is the only client), nanoseconds as a meaningful performance target, and the ever-present cautionary tale of Knight Capital’s 2012 $440M bug that nearly bankrupted a peer firm. Build-and-own culture: engineers own from idea to support; new hires get real production changes day one and are expected to become domain experts within a year Three-layer stack: signals (market data, ML pipelines) → strategy (risk-enveloped decisions with automated trade-blocking) → execution (hard separation of concerns — no logic beyond executing the trade) Platform engineering at scale: 30-40% of engineers on platform (vs 15-20% typical elsewhere); a globalization push since ~2023 consolidating regionally duplicated systems Languages with purpose: C++ for low-latency, Python for modeling (with serious performance forks like optiver-asyncpg), Rust emerging for research tooling, C# for trader GUIs, VHDL/SystemVerilog for FPGAs CI/CD on bare metal: custom hardware and custom Linux kernels mean CI needs pre-planned capacity like production; GitHub Actions with a custom observability layer for queue time metrics Custom hardware: own FPGAs and ASICs; the retreat system (reprising the options surface after each trade) went from seconds to nanoseconds through stack-level optimization AI shift: latency is now the floor, better models are the differentiator; Optiver built an AI gateway and MCP hosting platform where users are both humans and automated agents An extreme environment where every technical choice is a business choice — and the trade-offs between speed, risk, and reliability are unusually clear. The platform investment ratio alone signals how seriously they take developer experience and consolidation.
Matheus Lima argues that the standard senior engineer checklist — architecture, communication, ownership, leadership — misses the one core skill that actually separates senior+ engineers from everyone else: reducing ambiguity. A mid-level engineer can crush a well-defined problem with a clear spec and reasonable constraints. The gap appears the moment the problem is fuzzy — “improve performance,” “fix the onboarding flow,” “think about scaling.” Senior engineers ask questions nobody else thought to ask, separate signal from noise, and decide what to do now versus what to punt They derisk projects: turning “I don’t even know what this is” into “two small projects and one thing to cut” The clarifying work is invisible — when done well the project just goes smoothly, but someone did the hard work upfront Four questions seniors ask: (1) What problem are we actually solving? (2) Who is the user and what’s painful? (3) What assumptions might be wrong? (4) What’s the downside if we’re wrong? Most companies hire for this wrong — job descriptions list tech and years, interviews test LeetCode, neither measures ability to turn vague requirements into shippable plans The author’s test for whether you’re operating at a senior level: what do you do when someone hands you something abstract? If you spend time upfront making it concrete enough for your team to execute with confidence, you’re already there. If not, the good news is this isn’t talent — it’s practice, starting with the next vague ticket assigned to you.
An InfoQ essay from the Certified Architect Program argues that software systems are more than code — they include the shared mental model, or “theory,” held in the minds of the people who build and maintain them. When that theory erodes, the system becomes unevolvable even if every quality gate passes. Three forces are quietly eroding comprehension: Knowledge fragmentation. Decentralized decision-making optimizes flow but fragments the global picture. Teams understand their local domain but lose the “why” behind systemic boundaries. Team churn. Departing members take theory with them. New hires rebuild from artifacts that record the what, not the why — so they fall back on tactical patches instead of systemic improvements. AI-generated code. GenAI compresses the implementation layer where comprehension used to form naturally during design and coding. The result: code that passes every gate but nobody understands. The article proposes concrete signals to monitor the decay: ...
A companion to Rachel by the Bay’s earlier essay on the split between dead text files and living code — this one runs the problem in reverse. When a config file has to name an OS-defined magic value like O_NOATIME or TIOCM_RTS, the value arrives as a string, and something has to turn it into a number at runtime. In C this is trivial: include the header, use the symbol, resolved at compile time In a generic config-driven tool, a lookup table only covers symbols you knew about in advance Ask for O_SHINYTHING — a value the table doesn’t have — and the tool can’t express it The standard fallback is a glorified eval: write a tiny temp.c that prints the value, compile it, run it, parse the output. It’s the same trick autoconf-generated configure scripts use — and it quietly depends on a compiler existing on the target system. ...
An essay on the quiet incentive problem in engineering teams: the engineer who overbuilds gets a compelling promotion narrative, while the one who ships the simplest thing that works gets nothing. The thought experiment: Engineer A ships a simple 50-line implementation in two days — invisible in a promotion packet (“implemented feature X”). Engineer B builds a pub/sub system, a new abstraction layer, and a config framework over three weeks — and his work “practically writes itself into a promotion packet: designed a scalable event-driven architecture, introduced a reusable abstraction layer adopted by multiple teams.” Her work was better; his was narratable. Nobody gets promoted for the complexity they avoided. The incentive problem starts before hiring: in system-design interviews, proposing the simple answer gets “what about ten million users?” — so you add queues, sharding, more boxes, and learn that complexity impresses people. Design reviews do the same: “shouldn’t we future-proof this?” sends engineers adding layers for problems that might never materialize. The essay is careful to distinguish complexity from unearned complexity — “we’re hitting database limits and need to shard” vs “we might hit database limits in three years, so let’s shard now.” The path to seniority is knowing when NOT to use tools: “Anyone can add complexity. It takes experience and confidence to leave it out.” The fix for engineers: make the judgment visible — instead of “implemented feature X,” write “evaluated three approaches including an event-driven architecture and a custom abstraction layer, determined that a straightforward implementation met all current and projected requirements, and shipped in two days with zero incidents.” The fix for leaders: change the review question to “what’s the simplest version we could ship, and what specific signals would tell us we need something more complex?” — putting the burden of proof on complexity, not simplicity. “If we keep rewarding complexity and ignoring simplicity, we shouldn’t be surprised when that’s exactly what we get.”