Latest Posts (20 found)

Bliki: Interrogatory LLM

When we need an LLM to perform a complex task, we often need to feed it a lot of context. Coming up with a design for a new feature requires descriptions of how we want the feature to appear to the user, guidelines on how it should be implemented, information on external systems to consult, and so on. All this can be several pages of markdown. The obvious way to do this is for a human to write this context, but an alternative is to use an LLM to write this context after interviewing a human. The way I can do this is to prompt the LLM to interrogate me. It should ask me all the questions it needs to create this appropriate context. I can feed much of the information it needs, and tell it other sources it needs to consult if it can't figure those out itself. Once it's done, it can then create the context report for another session (perhaps with another model) to carry out the next step. I first saw a decent description of this approach in Harper Reed's blog . A striking element of his approach is insisting that the LLM ask only one question at a time. (When I tried it, I found it needed to be frequently reminded of this.) Another way to use an interrogatory LLM is to give it a document, such as a software specification, that captures knowledge about a domain - and then ask the LLM to interview a human expert to determine if the document is accurate. This is an alternative to getting the human expert to read the document to review it. People often find reviewing hard, so a conversation with an LLM might be more fruitful, particularly if the document isn't well-written. Naturally we can use both of these, using one interrogatory LLM to build a document, then using other interrogatory LLMs to review it with other experts. The above is getting an LLM to create or assess context for a particular use of an LLM. But the technique is more broadly applicable. I've become a natural writer, someone who finds the process of writing an essential part of thinking. To really understand something, I need to write about it. But different people are different. Many folks find writing hard, often very hard. This can be a real problem when we need to get information out of someone's head into a form that other humans can consume. Maybe such people would find it easier to ask an LLM to interview them than to write a document themselves. Certainly the result will have that tang of AI-writing that folks like me shudder at - but that's better than not having the information itself, either due to rushed writing or no writing at all.

0 views

An Interview with Ben Thompson at the MoffettNathanson Media, Internet & Communications Conference

An interview with me about the implications of the compute shortage on Aggregation Theory, consumer AI, and more.

0 views
iDiallo Today

It's funny because it's true

I made a joke online. Based on Internet upvote points, it was pretty funny. OK, I didn't come up with the joke, but it was a perfectly timed reference. A few days back, Cliff Stoll, of the Klein bottles, submitted a post on hackernews titled: Rumors of my death are slightly exaggerated First of all, I was surprised that Cliff frequents hackernews. Second, I didn't know that he was supposed to be dead. Yet, he wasn't since he is writing to say that he isn't dead. Apparently, there was a post on facebook that told his story and claimed that he had died in May of 2024. I was shocked to hear it. I've always admired Cliff and his work. But then again, he was the one who posted it on HN. Large language models learn facts by scraping the web, including facebook. So an LLM had ingested this information and regurgitated the information as fact. Wikipedia also used the facebook post as reference for his death. AI hallucinations are getting ambitious. A couple people recently emailed, asking whether the Klein bottle business was still operating after my death. “Huh?” I thought. “I ain’t dead yet.” After some digging, I discovered the source: an AI-generated review of The Cuckoo’s Egg circulating on Facebook. Alongside the usual synthetic praise and fabricated details, it confidently announced that I had died in May 2024. Apparently AI has now advanced to the point where it can kill people off before they notice. Mark Twain once wrote, “Reports of my death are greatly exaggerated.” I never expected to field-test the quote personally. source: [redacted to stop the spread] Cheers, -Cliff It was a funny story. It reminded me of the story of Doc Daneeka in the book Catch-22. Doc Daneeka is an army doctor who is afraid of flying. He bribes other soldiers to add his name on the flight manifest so as to appear as if he had performed his mandatory flight time. One day his name is entered in the manifest, the plane takes off, then crashes. The army checks the logs and sees that his name is in the logs. The army sends a generic message to his wife. I decided to respond in kind to Cliff’s post. Oh we already mailed the letter: "Dear Mrs., Mr., Miss, or Mr. And Mrs. Stoll Words cannot express the deep personal grief I experienced when your husband, son, father or brother was killed, wounded or reported missing in action" It was funny. I got many Internet points. But the last thing I expected was a response from Mr. Stoll himself: Oh my, but you know more than you can guess. About a year ago, my wife passed on. While deep in grief, I began receiving letters from financial institutions and banks that began, "Dear Mr/Ms Stoll, we offer our sincere condolences ..." How can a corporation have "sincere condolences"? They're the last place I'd go for comfort or sincerity. Everyday Catch-22 seems to become less and less absurd. 1984 is becoming a reality. Brave New World is the world we live in. These authors have become oracles. Somehow, the joke wasn't funny anymore. Because it was true.

0 views

Sweet Smell of Success

At its core, Sweet Smell of Success is about two men. At the beginning of the film, you think — while similar — one is decent, just desperate, and the other is beyond saving. By the end, you understand that both men are evil; the only thing separating them is the amount of power they wield. These two performances by Burt Lancaster and Tony Curtis are flatly terrific. There is little to say, because I've concerned myself much more with the 60s and 70s than the 50s, and so I can't say much about how these roles are in conversation with their prior oeuvre. But it is plainly clear that the screen bursts alive whenever either of them is talking. The rest of the film is a push-pull: a fairly standard and at times cartoonish melodrama — filled with an evil that feels more cartoonish than banal as each act progresses — rescued by the best window dressing in the world, and a whiplash script that finds entertainment and grace in its brief moments of joy. The director wrings a lot of tension out of how lovely every individual scene feels at the onset. Beautiful jazz soundtrack. Beautiful Manhattan nightclubs. Filmed and captured with just the right amount of realism. And then, the decrepit material disgust they're all wading through. I don't really go for morality tale movies at this point. While there's a certain world-weariness and hardscrabble wisdom to the proceedings here that might have been more winning with contemporary audiences, it's not exactly breaking news to me that owners of media corporations can be childish, petty, and controlling. Perhaps my fundamental flaw with viewing the film is that I think it hinges on a dwindling confidence that our protagonist is going to, at some point, snap out of it and do the right thing — even though it's so aggressively telegraphed that he won't. It seems odd to spend so much time criticizing a movie I thought was very good, so let me end with this: it is a smart, beautiful, honest movie that does not pull any punches.

0 views

Just aim the cannon correctly

James Shore has a post I found myself nodding along to until the very last step, where he loses me. The thesis is clean: Your AI coding agent, the one you use to write code, needs to reduce your maintenance costs. Not by a little bit, either. Productivity over the long haul, he argues, isn't bounded by how fast you can produce code — it's bounded by maintenance cost, which compounds. Any coding agent that accelerates production without taming maintenance is, definitionally, a debt-laundering operation: it lets you skip the bill today and pay it forever afterward. Each individual claim is, I think, correct. Code is debt; maintenance compounds; an agent that bolts on features faster than your team can absorb them is, given a long enough horizon, an anti-productivity tool. The conclusion Shore stops just short of stating — that current LLM tooling is, on net, bad — is where I get off the train of thought. A useful frame that I like across a variety of contexts is that of a difficulty score. The idea is straightforward: every recurring operation in your organization has some friction associated with it, and you can roughly approximate that friction with a back-of-the-envelope cost function. For something like opening a pull request , my version goes: For support, it might be: The specific weights don't really matter. The point is that once you have a function, you can take a derivative — you identify the things that are Bad and then you start taking discrete steps towards reducing them, with the overall goal of getting the score down as low as possible. And LLMs are, in my experience, fantastic at bringing these scores down. The bulk of what I've spent my own LLM-augmented time on at Buttondown in 2026 has been on this axis — squeezing the inner loop , trimming dependencies , handing diagnostic and scoping work to agents in the background — and the return has been outsized. Conversely, where I see LLMs deployed in the most deleterious manner — and where I think Shore's argument probably finds the most purchase — is when the relationship between the tool and the codebase is purely additive. LLMs are very, very good at adding features. They are also, more insidiously, very good at telling you that adding a feature is a great idea. 1 I have, on multiple occasions, tried to talk a coding agent out of building something. It is genuinely harder than the opposite, which I find both funny and faintly horrifying. You can ask any coding agent whether it should build the thing you just described to it, and the answer will essentially always be yes, with concomitant action plans and bullet points that it will litter throughout the codebase. The failure case I see in organizations that rhymes with Shore's point is along those lines. If scaffolding a feature took a week, you thought hard about whether to scaffold it. If it takes an afternoon, the answer skews toward yes, and yes, and yes, until you wake up one morning with sixteen new endpoints and no real idea why any of them exist, nor any graceful seams across them. But you can simply not use the tool that way, in much the same way you can simply not use Playwright as a full substitute for a testing suite. Here's a rough playbook: None of this is LLM-specific 2 In general, I think a useful framing device for reading essays about LLM-assisted engineering is "how much of this rings differently if they're just talking about all engineering writ large?" . The failure mode of letting maintenance debt accumulate without ever asking what specifically is making my life hard predates LLMs and will outlast them. What LLMs do is give people (and organizations) a fast forward button: they let the organizations that were already losing to maintenance debt lose faster, and they let the organizations that have their score-keeping in order pull away further. All of which is to say: I agree with Shore on the diagnosis. I just don't think the cure is to abandon the tools — it's to point them at the right operations, with eyes open about which ones, and to remember that adding code is the most expensive thing a coding tool can ever do for you. +1 point per ten seconds of wall-clock time spent waiting on tests or CI +5 points per tool you have to context-switch into (docs, dashboards, terminals) +1 point per click +10 points per manual check you run before merging +5 points per click required to triage a ticket +10 points every time the answer isn't simply a link to documentation we already have +25 points every time you have to log into the user's account because the relevant data isn't surfaced to support ×1.25 per follow-up response from the user Define the difficulty scores for the operations that matter. Write them down somewhere your team can bikeshed (non-derogatory, of course) and flesh them out. Triage the obvious low-hanging fruit (which is always much more than one assumes) against all the other work to do, biasing heavily towards this stuff because it's inner-loop. Ship the improvements.

0 views

Refactoring English: Month 17

Hi, I’m Michael. I’m a software developer and founder of small, indie tech businesses. I’m currently working on a book called Refactoring English: Effective Writing for Software Developers . Every month, I publish a retrospective like this one to share how things are going with my book and my professional life overall. At the start of each month, I declare what I’d like to accomplish. Here’s how I did against those goals: I keep feeling like I’m close to done, but then I spend more time than I intend to on bug bounties. Revenue dropped for the book, as I haven’t done any marketing since March . Instead, I’ve been getting distracted by bug bounty hunting . I’m glad I’ve been able to skate by on past effort, but I see the numbers trending toward zero if I neglect marketing. For the past three months, I’ve been spending a lot of time using AI to find security vulnerabilities. I haven’t talked about it publicly because I didn’t want to attract competition to the limited supply of bug bounty programs. I wasn’t sure if other people realized just how effective AI is at security research, but I think the cat is out of the bag . If you haven’t been following along with AI and security research, Firefox is an astonishing case study. Throughout 2025 (before AI was any good at security research) Mozilla and external researchers collectively found 10-20 security vulnerabilities in Firefox each month. In February 2026, Anthropic used Claude Opus to find 22 Firefox vulnerabilities . In other words, that month, Anthropic alone found more than everyone else combined in any of the previous 13 months. Two months later, Anthropic used Claude Mythos to find a whopping 271 more vulnerabilities in Firefox. I sort of spotted this early, but I got it slightly wrong. Back in January, I thought that AI might be able to revolutionize cybersecurity research, but I thought the value was in creating security tools. I was using AI to write fuzz testing tools and was amazed at how much faster I could perform fuzz testing than when I did it by hand . Despite the fact that I could write fuzzers 10-20x faster, it turned out that my strategy was way more work than was necessary. Instead of asking AI to create a fuzz testing tool and evaluate its output, you can just ask AI, “Hey, look at the source code and tell me all the vulnerabilities.” After I saw how good AI was at directly auditing source code, I stopped fuzzing and focused on source auditing. I’ve now reported 50+ bugs to five different bug bounty programs and earned about $10k in bug bounties. While I’ve successfully used AI to find security vulnerabilities, I’ve been less successful at finding companies willing to pay me for my findings. Here are my results so far: So, the $10k from vendor 4 only took two weeks of part-time work. That would be a great return on investment had I not also spent 6+ weeks on bounty programs that paid nothing. It would also be great if I could find more vendors like vendor 4, but I don’t know how to do that. I’m now torn on how to allocate my time between the book and bug bounties. Here’s my thinking: Rationally, I have a hard time justifying why I should continue chasing bug bounties, but I do want to keep at it a little bit, maybe like a 70/30 split between the book and bug bounties. A third possibility is that instead of chasing bug bounties, I teach people what I’ve learned in the last few months about using AI to find security vulnerabilities. I’m thinking about offering a small, cohort-based course where we find bugs in open-source projects. We’ll pick projects with no bug bounty attached so that students can internally share findings without worrying about someone running off with their reward. The format will be some combination of live or recorded screencasts + a private group chat for 2-4 weeks. The course is not going to be about making money from bug bounties. Maybe I’ll cover that some, but that won’t be the focus because that’s not what I’ve learned most about in the last three months. The course will be about using AI to find security vulnerabilities in large codebases. I’ll show the techniques I’ve learned for getting AI tools to focus on likely areas of bugs and avoid wasting time and tokens on bad leads. You can apply these lessons internally with your own closed-source code or on open-source projects you want to help secure. If you’re interested, sign up for my interest list below: A few weeks ago, I saw a question on reddit from someone who wanted to delete their Facebook account but capture an archive of their data in a usable format. That reminded me of a project I’d seen on Hacker News but never explored much called Timelinize . Timelinize lets you import data you exported from Facebook, Google, Twitter, and similar services, and the app creates a unified timeline to explore your data. The creator is Matt Holt , who also created Caddy , the popular reverse web proxy. Timelinize still feels pretty alpha-stage, and I had to add a bunch of local patches to make it usable, but I like where it’s going. I plan to upstream more of my patches as I use it more. Whenever I find a local, offline solution for something that previously required a cloud service, it feels oddly refreshing. When I switched from streaming services to Jellyfin , I was surprised at how different it felt to just watch what I’m watching without a company watching me back for ways to squeeze money from me. The weird thing was, when I watched Netflix or HBO, I never consciously thought, “Oh no! I’m being monitored.” But when I started exclusively watching TV and movies locally, it was as if I spent so much time in an office cubicle that I forgot that there’s an outside at all. Then, I went outside and enjoyed fresh air and sunshine. Metaphorically, I mean. Literally, I was still sitting inside watching TV on my computer. But it was so much faster and freer than before! I had a similar “breathing fresh air” experience with Timelinize. Timelinize’s interface is user-oriented, which makes me realize just how user-hostile the interface is on cloud platforms. Facebook and Twitter don’t want you to just scroll through your old messages because that doesn’t make money for them. To discourage you from reading your old messages, they make the experience subtly uncomfortable: they squeeze the conversation into a tiny box, they force you to stop and wait for new messages to load every few seconds, and they constantly show you distracting notifications to lead you back to the new content they can monetize. With Timelinize, the reading experience is designed to let me just read my archive. There’s nothing trying to steal my focus and check out what’s new because Timelinize shows a historical snapshot. I find it fun to jump to a date 10 years ago and read what my conversations were at the time. The Timelinize interface lets you read your conversations without trying to steal your focus with notifications. I didn’t follow React2Shell at the time, but it was a critical vulnerability in React.js that allowed an attacker to gain code execution on many React.js and Next.js apps. Last week, the two researchers who discovered React2Shell wrote about what happened behind the scenes: Lachlan’s post got more attention, but I found Sylvie’s more interesting, especially given that she was a 20-year-old college student at the time. Lachlan and Sylvie both realized they’d found a “nuclear bomb” that affected hundreds or thousands of major websites. After reporting the bug to Meta (who maintains React) and Vercel (who maintains Next.js), they wanted to identify other bug bounty programs that would pay them for their work on this massive bug. The researchers couldn’t disclose the bug to the other vendors until Meta publicly announced the security advisory. The problem was that once React2Shell was public, Lachlan and Sylvie would lose their edge over everyone else rushing to claim the same bounties. To get a head start, Sylvie scouted bug bounty programs during the bug blackout period and checked whether those vendors’ sites were vulnerable to React2Shell. That way, as soon as Meta announced the vulnerability, Sylvie and Lachlan could claim these third-party bounties. The problem was that before React2Shell became public, Vercel created a filter for the bug in their web application firewall (WAF) that would protect Vercel customers even if the customer sites were running vulnerable versions of React or Next.js. Meta and Vercel also worked with Cloudflare and similar WAF platforms to teach them how to filter React2Shell attacks. So, after Meta announced React2Shell, Sylvie tried reproducing the bug against the sites she scouted ahead of time, but the bug didn’t trigger. Almost all of the sites with bug bounties were on Cloudflare or Vercel, so the WAFs blocked Sylvie’s exploit. So, now Lachlan and Sylvie had to figure out how to sneak their exploit past Cloudflare’s and Vercel’s WAFs to trigger React2Shell, but bypassing enterprise WAFs is a massive research project in itself. Fortunately, Sylvie found a bypass in Cloudflare’s WAF and five distinct bypasses in Vercel’s. Interestingly, the “vast majority” of what Sylvie earned came not from React2Shell itself but for the WAF bypasses, as Vercel paid $50k per reported bypass. If you’re interested in learning about using AI to find security vulnerabilities in your team’s code, sign up for my interest list. If there’s enough interest, I’ll put together a course. I’m torn between focusing on my book and pursuing security bug bounties. I’m considering a course to teach what I’ve learned about using AI to find security vulnerabilities. Result : I’ve still got about 1-2 weeks of writing left Vendor 1: Meta I submitted eight reports, including one remote code execution bug. I received no response for several weeks. I found email addresses for developers that worked on the product and pinged them, and they escalated my reports to get them past triage, but there’s been no movement since then (two weeks and counting). Vendor 2 I submitted one report. Vendor triaged it in one business day, but said it would be several weeks before they could investigate thoroughly. I haven’t heard anything in over 30 days. Vendor 3: I submitted one report. Vendor claimed it was a duplicate, so no bounty. Vendor 4 I’ve submitted 40ish reports. Eight were paid after two weeks for a total of $9,700. Two were rejected as duplicates. The remaining are all awaiting triage, though the most valuable ones were in the first eight that have received payouts. Vendor 5: Firedancer (crypto project) Found a few medium-severity issues. When I started the bounty reporting process, I realized that they require researchers to upload their passport to a service I’ve never heard of, so I stopped there. Their program rules are also sketchy in that they seem to contradict the rules of the bounty platform they’re using. Focus on my book Pro : The book is nearly done, so if I focus on finishing, it will be complete and more valuable than a partially-finished book. Pro : The book is something only I can create, whereas lots of people can participate in bug bounties. Pro : I’m already late on delivering the book, so finishing it makes me feel less guilty about making readers wait. Pro : I can talk publicly about my book, and not only does it help me think out loud, it helps new readers discover the book. Con : The expected value of the book feels lower than bounty hunting, at least in the short-term. In theory, I could find a $100k bug next week, whereas it’s unlikely I could do anything that would drive $100k in book sales by next week. Focus on bug bounties Pro : I made more in two weeks of bug bounties than I did in all of 2025 on my book. Pro : There’s still a massive amount of undiscovered, bounty-paying bugs that AI tools can find. Pro : If I pause for a few months, the value of the remaining bugs will be significantly lower, as many other researchers will have claimed the easy-to-find bugs. Con : Participating in bug bounties is frustrating, as you have no leverage. The vendor can completely lowball or shaft you, and you have no recourse or negotiating power unless you sell the exploit to buyers who want to use it for nefarious purposes. Con : Bug bounty hunting is addictive like gambling in that there are variable rewards that appear semi-randomly. Con : Bug bounties push me back into bad AI usage habits . If I have an AI agent searching for bugs in the background, I constantly want to check on its progress and redirect it based on early results. Con : I’m much more limited in what I can share publicly about my work, both because bounty programs often require it and because I don’t want to attract competition to the same places where I’m focusing effort. Early interest list - Using AI to find security vulnerabilities “The React2Shell Story” by Lachlan Davidson, the lead researcher on finding the vulnerability. “The React2Shell Story and What Happened Next.js” by Sylvie Mayer, who assisted Lachlan in exploring the vulnerability, notifying vendors, and identifying bug bounty programs that would pay for the vulnerability. Published new chapters: “Improve Your Writing with AI” and “Meet the Reader Where They Are” Held a live session with readers about using AI to improve writing Reported a bunch of security bugs through bug bounty programs It’s better for me long-term to focus on my book than on security bug bounties. The hard part is that bug bounties are so short-term rewarding, whereas the rewards for the book typically lag my investments by at least a month. It’s unexpectedly satisfying to migrate from a cloud service to something you run locally. Get Refactoring English to “content complete.” Create a tool that allows Refactoring English readers to give feedback as they read the book. Early interest list - Using AI to find security vulnerabilities

0 views

Flat/Non-higher-order construction of ANF via mutable holes

This post will describe an algorithm for constructing an ANF/similar IR from a functional-like base language with no closure usage, and with no related excess space requirements. This algorithm is as far as I know not new, and has apparently been known in imperative compilation for a while. However, I admittedly have no source for this, nor have I seen it described for functional-like languages. Thanks to Ryan Brewer and rpjohnst for their inspiration on this. If you are only interested in code, please skip to Implementation. First, let us describe our input and output languages. Our input language will look like this: This is meant to echo some simple functional programming language, and contains all the elements needed to demonstrate the algorithm. Our output language will look like a lexically-scoped flat ANF-style construction, with all lets at the toplevel. The goal is to convert from our input to this language. The notable addition is the constructor in , the purpose of which will be described now. Imagine we are trying to convert the term When we arrive at the body of , we have a conundrum. We need to put the conversion of before , so that using is well-scoped. Hence, we must convert before we can continue. How do we use this conversion, though? 's content needs to be put in the field of 's , so it's not clear how to both convert before and to use 's finished conversion in . One "traditional" method of solving this is via continuations, where is passed a closure representing "what to do next", after it converts its body. We can then put 's content in that closure, which will be invoked later. This has two main flaws: This method resolves these. Recall that we left a field in our type. I will denote a hole like this: . The central idea is that our conversion of any given fragment will return: Consider this simplified example: When we convert , this signals for the conversion of . There are two steps to converting a - we must first convert the "head" ( ), and then the "body" ( ). Converting the will result in something of form Note that the hole is left to be filled later. This way, the conversion of 's head need know nothing about its environment. We represent this in code via the constructor, which contains a reference to a fragment that either may be empty ( ) or filled ( ). The conversion of the body can then proceed by first generating the expected addition, binding it to so it may be referenced later: We now need to get this fragment into the proper lexical scope. We can do this by plugging it into the hole left by the conversion of the head: Then, returning this fragment, the name bound ( ), and the reference to the inner hole, we can continue converting ; First, convert the head, using the name returned by the conversion of : Then, the body: And finally plug it into the hole returned by . We are left with a final hole we can plug with to be explicit about the end of a control flow path. One disadvantage of this strategy is that it does generate many unneeded names. Most of these can be avoided by carefully special casing certain , and the rest can be eliminated via a simple folding pass. Below is a sample implementation of this algorithm, in OCaml. I recommend toying with the conversion yourself, using or similar. In the following, I will "clean up" the output slightly, as to not make it unreadable. If we use our first example term: We can then plug the returned hole, as described. Via some inspection, we can verify this is indeed correct, and conforms to our ANF-like form, as expected. As mentioned earlier, the large amount of duplicate names can be mitigated through strategies such as special casing and folding passes. Clearly, the algorithm does not use closures, or any indirect jumps. It does not allocate any more than needed for the representation of the output program; there is no excessive closure allocation. I do not currently have a good way to test performance on real-world large inputs, but I have no reason to believe it would not perform better than an equivalent higher-order version. I believe this method should be extendable to CPS as well, although I have not tried as of the moment. The "usual" higher-order CPS conversion described in e.g. "Compiling with continuations, continued" looks quite similar to the higher-order presentation of ANF conversion, so I would be interested in whether it can be similarly massaged into a mutable form. It uses excess space. A conversion of a term will allocate ~2x the memory "needed"; it must allocate for the ANF construction itself, and for the closures needed during the construction. It is slower, due to the aforementioned closure allocation and application. The fragment itself. A name we can use to refer to what was bound in the fragment (In the conversion of addition/similar with nested content, names must be conjured.) The reference created by the hole, so that it may be filled.

0 views

Browsers Treat Big Sites Differently

Some browsers ship code that checks which domain you’re visiting and changes how the page renders based on it. Yup, you read that right. If site == X , do Y . TikTok gets special treatment. So does Netflix. So does Instagram. And so does SeatGuru. Safari and Firefox both do this. Chrome doesn’t. That tells us something interesting. The source code is right there if you want to look. These are literal domain checks baked into browser rendering engines that say things like "if the user is on this domain, render this differently" or "if they’re on that domain, handle that API call differently." It’s not a bug. It’s a feature, and it ships to billions of devices. If you open Firefox and type in the address bar, you’ll see a list of site-specific interventions complete with toggle switches. Each one is a targeted fix for a specific website, and you can turn them off and watch sites break. Firefox’s WebCompat system injects custom CSS and JavaScript into specific domains, changes user agent strings for sites that sniff browsers incorrectly, and papers over bugs that would otherwise make the web feel broken. The interventions are tracked in Mozilla’s Bugzilla, complete with bug reports and sometimes failed outreach attempts to the sites in question. Safari’s WebKit engine calls them "quirks," and the file is publicly available on GitHub. Reading through it is an education in how the web actually works. Here’s one comment from the code: So the browser detects when you’re on facebook.com, x.com, or reddit.com and changes how it handles Picture-in-Picture video. These companies wrote broken video code, and rather than wait for them to fix it, the browser shipped a workaround to every user. Here’s another comment: Someone added domain-specific rendering code for SeatGuru, and the comment implies outreach was attempted. SeatGuru didn’t fix their site, so the browser fixed it for them. The commit history is a fascinating read. In just the last few months: Zillow’s floorplan images weren’t centering, TikTok was showing "please upgrade your browser" messages, Instagram Reels were resizing erratically during playback, Netflix’s "Episodes and Info" button was dismissing popovers incorrectly, Twitch was pausing PiP videos when you switched tabs, and Amazon Prime Video wasn’t letting Safari users watch at all. Each one got a domain-specific fix shipped to every single user. The quirks files aren’t just fixing broken sites; they’re often compensating for Chrome’s control over what "working" means in the first place. The pattern goes like this: Chrome ships a feature, developers use it because Chrome dominates the market, and other browsers scramble to either implement the feature or add site-specific quirks to paper over the difference. By the time Safari or Firefox catches up, the quirk has already shipped to millions of users. WebKit’s source code includes user agent overrides that make Safari pretend to be Chrome for specific sites like Amazon’s video pages and various streaming services. These sites sniff for Chrome and serve degraded experiences to everyone else, so rather than let Safari users suffer, WebKit lies about what browser it is. From the current Quirks.cpp source: Safari literally ships with a fake Chrome user agent string, ready to deploy when sites refuse to work otherwise. Firefox does the same thing, and many of its interventions are user agent spoofs telling sites "yes, I’m Chrome" because those sites actively block or break on non-Chrome browsers. The Mozilla wiki explains that some sites "block access completely, display a different design, or provide different functionality" based on browser detection. So Firefox ships workarounds. This creates a feedback loop. Developers build for Chrome because Chrome dominates. Their sites work best in Chrome. Users who hit bugs elsewhere blame the browser, not the site, so they switch to Chrome, reinforcing its dominance. These aren’t just cosmetic tweaks. Browsers change fundamental behavior based on your domain, including scrolling behavior, touch event handling, viewport calculations, and image MIME type handling. The list in WebKit alone runs to thousands of lines. Here’s one about simulated mouse events: The browser checks if you’re on Amazon and changes how touch-to-mouse event translation works for their product zoom feature. Amazon’s site assumes certain event behavior that Safari doesn’t provide by default, so Safari provides it anyway, but only for Amazon. There are quirks for storage access, scrollbar rendering, autocorrection behavior, and zoom handling. Each one is behind a domain check, and each one is compiled into the browser executable. You might have noticed something. I’ve shown you Firefox’s and WebKit’s , but where’s Chrome’s equivalent? Chrome doesn’t really need one, and not necessarily because Chrome is better engineered. The web is already built for Chrome. When over 80% of users browse with Chromium-based browsers , developers build for Chrome first. If a site works in Chrome, it ships. If it breaks in Safari or Firefox, they decide, knowingly or otherwise, that it’s less of a problem. Chrome doesn’t add quirks; it sets the agenda. When Chrome changes how something works, sites update to match, and other browsers follow or break. This is the asymmetry that runs through the modern web. When a site breaks in Safari, WebKit engineers add a quirk. When Chrome wants to change how the web works, Chrome just changes it and everyone else adapts. Chrome doesn’t need quirks because Chrome’s interpretation of web standards is the version that everyone else works to. This isn’t done maliciously and it isn’t entirely Google’s fault; really it’s the natural consequence of market dominance. Browser engineers will tell you the specs themselves are actually well-defined now. The HTML5 "living specification" approach solved the chaos of the IE/Netscape era by making specs match reality. The problem is that developers rely on unspecified implementation details, then blame non-compliant browsers when those details differ. While that may be true, it doesn’t change the outcome. When Chrome is the implementation everyone targets, Chrome’s unspecified details become the de facto spec. The same thing happened with Internet Explorer in the 2000s. When developers built for IE, sites broke elsewhere, and standards compliance became secondary to just making it "work in IE." We spent years digging out of that hole. A decade ago, the hope was that browser quirks would eventually disappear as the web became more standards-compliant. You could argue they did, but not for the reason anyone expected: the quirks didn’t go away, they just moved to browsers that aren’t Chrome. You might wonder why browser vendors don’t just contact the offending sites and ask them to fix their code. Sometimes they do, and there’s even a field in source code comments linking to outreach efforts, but consider the economics of that. A browser vendor’s job is to make the web work for users, and if a popular site is broken in their main browser yet works in Chrome, users blame the browser. Filing a bug with a third party and waiting weeks or months for a fix that may never come is a losing proposition when you can ship a five-line workaround tomorrow. There’s also the question of who you’d even contact. The developer who wrote the broken code might have left the company years ago, the team that owns that endpoint might not know it’s their responsibility, and the site might be in maintenance mode receiving security patches but nothing else. From the browser’s perspective, the choice is simple: fix it now, invisibly, and save everyone the trouble. A WebKit engineer wrote a blog post about removing a quirk for FlightAware. The site was comparing CSS transform matrix strings, but the CSS spec had changed how browsers should serialize the values, and the browser became compliant, FlightAware broke, and engineers added domain-specific code to fix it. Outreach eventually worked, FlightAware fixed their code, and the quirk was removed. But for months, Safari users had a working experience only because someone wrote an statement in the browser checking for . Your site might be getting special rendering treatment and you might not be aware of it. That quirk you’re benefiting from doesn’t show up in your error logs, and there’s no console warning that says "this browser is working around your mistakes." The fix is invisible by design. If you test mostly in Chrome, you’re especially exposed. Your site might work perfectly not because you wrote good code but because Chrome’s behavior aligns with your assumptions. Other browsers will have to choose between letting your site break for their users or adding you to their quirks file. Open your site in Firefox and Safari. Not occasionally, not before a big launch, regularly . The quirks files exist because developers didn’t do that. If you find your domain in one, consider auditing whatever it was they worked around. Not because you have to (after all, the web kept working without your intervention) but because somewhere an engineer at a browser you don’t use solved a problem you didn’t know you had. The specs are the map, but the quirks lists are the messy terrain. Standards were supposed to eliminate browser-specific code. We dug ourselves out of the IE era, celebrated, and then built exactly the same hole again around a different browser. Only now the browser-specific code lives in the browsers that aren’t dominant, patching over a web built for the one that is. Sites I’ve worked on are in these files. Yours might be too. And the lists are getting longer .

0 views

Commenting Guidelines

When commenting on this website, please keep the following points in mind: You may include HTML or Markdown in your comment. Comments are converted to HTML and sanitised before they are published on this website. All submitted comments are held for review. Whether a comment is published or not is at the discretion of the author of this website. Typically, only the following types of comments are published: Generally, rants are not published, even when the post you are commenting on is itself a rant. This website is the author's place to rant. It is not your place to rant. If you really need to rant, please do so on your own website. This guideline exists to maintain a high signal-to-noise ratio in the comments section. All comments deemed suitable for this website by its author become publicly available on this website at two places: on the comment page for the article you commented on ( example ) and on the overall comment index page at comments . Read on website | #meta You may include HTML or Markdown in your comment. Comments are converted to HTML and sanitised before they are published on this website. All submitted comments are held for review. Whether a comment is published or not is at the discretion of the author of this website. Typically, only the following types of comments are published: Comments that add new information or insight to the topic discussed in an article. Comments that provide a neutral, supporting or opposing viewpoint. Comments that report typos, errors or bugs on the website. Comments that contain good humour. Comments that express appreciation. Generally, rants are not published, even when the post you are commenting on is itself a rant. This website is the author's place to rant. It is not your place to rant. If you really need to rant, please do so on your own website. This guideline exists to maintain a high signal-to-noise ratio in the comments section. All comments deemed suitable for this website by its author become publicly available on this website at two places: on the comment page for the article you commented on ( example ) and on the overall comment index page at comments . Do not submit sensitive personal data in your comments.

0 views
iDiallo Today

Software Engineers are Obsolete

In my first interview for a developer position, I shared a link to my personal project with the interviewer. It was a website for learning how to program. I created it from the ground up. I built the PHP app, designed the database schema, made a nice design to tie it all together. I wrote down my process, and it became the first tutorial on the site. Then I collected tutorials from all over the web and displayed them on my website, which acted as a portal. There was a section for PHP tutorials, for Ruby on Rails, for .NET, etc. Each one individually curated by me. My interviewer was so impressed. I got the job. Later, I added a section where anyone could submit their own tutorials. It was fascinating how quickly people found my website and started submitting links. The tutorials were coming in so fast that I removed the verification system and let people upload links directly. But then my mind wandered. What if I start a blog? Yes, I had another blog before this one. I built an entire blog engine from scratch. A colleague found my blog. He was so excited that he shared his own with me. At lunch, we would discuss ideas, and that same evening after work, we would buy a domain name and start a new project. We shared tips and tricks on how to rank on Google. We had a skill, being web developers, and we took full advantage. When we had an idea, we would fire up our computers that same night and build it. Friends and family would come to us for validation. We were the ultimate deciders of what was a good idea and what was a bad one. We were the gatekeepers. We knew how to program, and nobody outside our circle could say otherwise. Now, friends and family don't come to us anymore. They go straight to ChatGPT, and it tells them their idea is brilliant . They launch their favorite AI agent, which builds their entire product from a single prompt. Some of them even manage to host it on the web, accessible to the world, and they are seeing their first customers. People who used to confuse Java with JavaScript now tell me they have a platform. People who don't even know what programming is are standing at the forefront of software innovation, advocating, evangelizing, and making money. This skill I spent years honing has been made obsolete by everyday people. We, the developers, are no longer the gatekeepers. In fact, now we need to keep up or risk being left behind. Some commenters online tell me I'm just jealous, that I need to embrace progress. I don't want to be obsolete. I'm on openclaw, moltenclaw. I have accounts on all the video generation websites. I have accounts on ChatGPT, Claude, Gemini, and Mistral. Just as I'm getting a hang of one tool, my friend who works in a warehouse tells me, "just use Perplexity for that." But Perplexity isn't enough, because another friend says GenSpark is better. For some reason I can't sign into my Manus account anymore. And apparently, to get the most out of it, I need to get Meta Ray-Bans. Everyone is empowered, no one needs me, and that's that. The developer is now obsolete. But then, I opened LinkedIn. My peers, fellow developers who for some reason all have the word "AI" in their job title, are saying the opposite. "Developers are not losing their jobs to AI," they say. "Developers are losing their jobs to other developers who use AI." They are vibe-coping to the max. The history of technology has always been a story of nearly missing out. I remember another job I applied for and totally didn't get. The company had moved all their client-facing apps to Silverlight. If you're wondering what Silverlight is, you might understand why I chuckled when the interviewer described their plight: they were struggling to find developers to help them migrate to HTML and JavaScript. I'm fairly sure that chuckle is why they never called me back. It's one thing to embrace new technology. It's another thing entirely to put all your eggs in one basket. Companies are betting everything on Silverlight. Sorry, I mean AI. Without thinking through what happens if things don't pan out. AI has lowered the barrier to entry. That's a good thing. More people can now bring a fresh pair of eyes to the software engineering field. But there's a problem. Those new entrants won't become better engineers over time. Why? Because they are not writing code, not reading code, not debugging code. Their growth path, with time and experience, is to become better prompters. What this means is that, amid all the noise, my role as a software engineer may seem obsolete. But in the long run, we will be back to square one, where engineers writing code with their own meatware will hold all the cards. These are the people who learned the hard way: by reading documentation, by debugging broken apps, by having their seemingly perfect Stack Overflow question closed as a duplicate. These are the engineers who will hold the keys to software. Not because they're guarding secrets, there are no secrets. It's simply that the new developer is not, and will never be, interested in learning. While we pride ourselves on producing more software than ever, it doesn't take long to realize that software is never truly finished at delivery. It has to be maintained. It's strange, computers whose entire purpose is to repeat the same process over and over, perfectly, somehow manage to degrade over time. My tutorial website, seemingly working fine, returned an error when I visited it after months of neglect. I restarted all the services and brought it back up. It was now full of spam and NSFW URLs. An application that worked perfectly yesterday is broken today. It could be a memory leak, unexpected input, or just users with fat fingers. Your completed application is suddenly incomplete, and you have to fix it. In an ideal world, we wouldn't keep producing more software. We would have working software, and less of it to maintain. AI thrives on quantity. If you need me, I'll be in the back, patiently waiting for you to realize you can't prompt your way out of a Silverlight migration. My rates just doubled.

0 views

What Time Is It?

On Palm OS, the interface for picking the start and end time of an event is represented as two columns, hour and minutes. The hours list either starts at 8AM and shows until 7PM (covering a full business day, or it starts at the next hour (if creating an event for today). Minutes are represented for every 5 minute interval, allowing every option to be shown at once. This interface is simple and requires an extremely low cognitive load to use. It's scannable and adaptive to the current situation (today vs another day). It limits options (ie you can't set a time of 12:33) to drive simplicity. If we compare to the time picker on Android, we can see it's significantly more complex. One must first tap the hour, then tap AM/PM, then tap the minutes section and tap the minute they need. While minute intervals of 5 are shown on the screen, the user is able to select specific minutes, if they know how (one must drag the circle to get a specific minute). The interface has many more taps, states and cognitive load. How about iOS? Like Palm OS, iOS limits you to 5-minute intervals. Similar to Android though, an additional interaction is needed to pick AM/PM. Picking hour and minutes is more involved as well, you must scroll the picker to the desired value. The Palm OS UI might not be the prettiest, but it's the fastest for most use-cases. The most common options (business hours and 5-minute intervals) are presented without the need for multiple states or scrolling. Setting the time is 2 taps away!

2 views
Unsung Yesterday

“This is where your mouse becomes a cryptographic instrument.”

A fascinating 9-minute video from PawelCodeStuff about randomness in the context of computing: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/this-is-where-your-mouse-becomes-a-cryptographic-instrument/yt1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/this-is-where-your-mouse-becomes-a-cryptographic-instrument/yt1.1600w.avif" type="image/avif"> It explains those weird moments where sometimes the computer asks you to wiggle your mouse – to generate unpredictable numbers – although the specifics of what exactly was random in my wiggling was a surprise to me. There is something poetic about computers yearning for that one thing they can never get – complete unpredictability – and collecting it in a little pool like you would something very precious. Also fascinating that in modern CPUs, there now exist hardware components that gather truly random data from the real world. While I have never needed true randomness in my design career, knowing how to control pseudorandomness (specifically, how to replay it) has been helpful. Here’s an example. In my essay about Gorton , there is this interactive bit where you can drag a slider for “messiness.” With regular pseudorandomness, the experience is wiggly and gross: But when you always restart the prng from the same seed (“the Groundhog Day maneuver”), it feels much better: #details #motion design #security #youtube

0 views
ava's blog Yesterday

new challenges at work

In the past, I have complained about some aspects of my work here and there. As I continue to grow, get more qualifications, visit conferences, and apply to interesting positions, I've put more effort into transforming the place where I'm at, to the best of my abilities. I've repeatedly asked for more work, I've asked for different tasks, and I helped create a new role. Not replacing my current role and work, but something on top/on the side next to my core tasks. I needed change and something worth logging in or coming into the office for, and of course I wanted to pivot more into my desired field. That brings some new challenges, which are desired, but can be uncomfortable at first. Years of doing the same tasks with comparatively little cooperation and following repetitive processes never forced me to put a lot of thought into what I put out, so to say. That can be very nice, and in the beginning, it was hard enough learning everything and doing everything correctly. With my core work, no one asks me to create anything from scratch, make any decisions, or organize anything independently; it's all set in stone. If I wanted to, I could just spend years doing the work-equivalent of "minding my own business" and keeping my head down, in which I work off what came in that day based on our rigid standards and use fixed email templates (not even having to formulate my own sentences), nothing more, nothing less, unbothered. That's what I did for years as I got used to everything, and as I was very sick. But now, when I want to do more challenging work, I notice that years of working like this have made me very comfortable. Not lazy, but it feels unusual and slightly scary to suddenly have a more "active" part of work where I actually have to plan meetings, host and lead them, prepare slides, and even approach people first about needing to find time to discuss something together. Completely normal office tasks for others, of course, and it's what I wanted to not stagnate further in something that bores me, but my brain still perceives it as a threat. Due to internal restructuring and moving of employees, we lost our sub-department's IT coordinator 1 (each sub-department has to assign someone). I asked my boss if I could be the new one, and she agreed. Unfortunately, at least in our department, this title is more decorative than anything else, as the IT coordinators don't even have any meetings to discuss anything at all. This has generally worked fine enough, as in " we are surviving ", but now with different AI model rollouts and other software changes, I notice employees becoming more and more confused and helpless, and a more proactive approach would be nicer. When I asked my boss for permission to be one, I said I would like to organize a meeting of all coordinators to discuss some challenges and more, and both her and the department head thought this was a good idea and asked me to schedule one soon. I didn't expect how much this task would make me freeze up; I didn't wanna be the newcomer in a group who piles more work and yet another meeting onto the other people as a first move. So I obsessed over a good way to introduce this, and how to make the first meeting worth it. I didn't want everyone to show up, discover we have nothing to discuss, and leave after 5 minutes. The invitation mail should stress that this is just a first, casual meeting in which we will talk about x, y and z topic, and then determine whether this should happen again and in what frequency. I also kept pondering whether I should also already prepare a topic/mini-presentation to not come with empty hands myself as an organizer, and what that could be, putting a lot of pressure on finding something good enough. The final hurdle was that no one in my department apparently even had a full list of who the other coordinators are; had to research that myself somehow and ask around. All that made me put off scheduling anything for a good 3 weeks. Yesterday, I finally dealt with this mess, as the task became more and more pressing and uncomfortable to think about, threatening to become this huge anxiety beast strangling me. Detangled my feelings, set realistic expectations, and scheduled it to mid June to have a bit of time. At the same time, I am finally officially the data protection coordinator of my department. My work never had any before, no other department has one either. This is just my department wanting to lead by example, and admittedly, also accommodating me and my ambitions, as I have asked for this for months. Leadership up top has repeatedly thwarted my attempts to move into the data protection team, or officially implement coordinators house-wide, and refused to even discuss it or process it in the idea management system, so this is my little rebellion, you could say. Doing things from the bottom up. I have already prepared the slides they will use to announce it in the next department meeting and the meeting of all department heads. I will also have to prepare a short presentation about data protection challenges in our department, scheduled around Q3 or Q4 of 2026 as I need time to get an overview of everything. I'll have to meet up and interview a lot of people about their team's data workflows to see what needs to be adjusted, write some analyses, write deletion concepts, create awareness, ensure compliance, and more. I'll also be the person to go to before the data protection officer is getting involved. It's what I wanted, but internally it also makes me very nervous. I finally get to create things and success will be about the quality, not just that something was done; but it opens the door for thoughts about whether I am good enough or not. Merely following process steps as described makes it easy to just be a bot that gets things done; creating things yourself, sharing your own ideas and opinions exposes you as a person, makes you vulnerable. There are people working there that will finally see that there is a person with a brain underneath the years of automatically generated emails they received in my name. There is no one else to watch and learn from, as I am the only one, and I get to make things up as I go for this new role. I will be the blueprint, for now. There are horror scenarios in my head of not knowing something in a meeting and everyone thinking I am an impostor who doesn't really know anything. That's not how real life goes, of course, and everyone is usually understanding when you say " Sorry, I will have to look that up and get back to you about that. ", but you know how brains are. I'll have to learn from every meeting. I am scared of not doing a good job and doing it all a disservice. The culture is an aspect of it too, because unfortunately, my place has a reputation of not being kind to ambitious people, and many people being rather hostile if anything is asked of them - time, expertise, feedback, a change in routine, a little bit of grace; anything. There are also a few coworkers that have proven again and again that they are unable to view younger people or people lacking this or that university degree as worth taking seriously. That's what I will be up against, and my own harsh standards I have for myself. I'm trying to reassure myself that I have time to figure things out and that I need to make mistakes to improve. Reply via email Published 13 May, 2026 The IT coordinators' role at my workplace is to share IT knowledge around in all kinds of teams so it isn't just concentrated in specific areas, and to ensure everyone is up-to-date on internal policies, new software options and more. They're also a sort of first responder to task-specific tech problems in that specific team before annoying our general helpdesk. The communication of our IT department can be lacking, and not everyone has the time to keep on top of new things (like the sudden rollout of Copilot recently, new options available in Teams, etc.), so having these people "posted" in each sub-department to share news and developments was supposed to help that. ↩ The IT coordinators' role at my workplace is to share IT knowledge around in all kinds of teams so it isn't just concentrated in specific areas, and to ensure everyone is up-to-date on internal policies, new software options and more. They're also a sort of first responder to task-specific tech problems in that specific team before annoying our general helpdesk. The communication of our IT department can be lacking, and not everyone has the time to keep on top of new things (like the sudden rollout of Copilot recently, new options available in Teams, etc.), so having these people "posted" in each sub-department to share news and developments was supposed to help that. ↩

1 views
Unsung Yesterday

Mailbag: Photoshop’s focus post

The post about some of Photoshop’s new dialogs traveled through some of internet’s pipes and alleyways. Michael Tsai has a nice roundup of reactions ; let me pick a few things that caught my attention. 1. Nick Heer at Pixel Envy made a discovery that Photoshop’s new windows are… websites : Maybe it really is possible to build a web app that feels platform native. But I have never used one — not once — and for this mess to be increasingly used in the industry-standard professional suite of creative tools is maddening. I think it is possible – especially in the realm of classic form fields – but you really have to care and step up and test and replicate a some stuff that the operating system controls give you for free. (As an example, if the web platform/​Electron don’t give you access to the “keyboard navigation” OS accessibility setting, you’ll need to build a bridge from the OS to pass it through. This is how Figma’s Electron app got haptics, for example.) It is true that we don’t see that level of effort often. But there are also bad native interfaces, and there might be more; Roger Wong recently made an interesting observation that stuck with me. Emphasis mine: The mechanism differs but the outcome is the same: the platform stops being a place a designer can rely on. […] [Text user interfaces] are back because the platforms quit , and the curriculum can’t fix that. I think I agree with this; I’ve felt there haven’t been a lot of improvements in native desktop interfaces recently. In the mid-1990s, Apple was losing to Windows 95/98, and after years of falling by the wayside, the team eventually got their priorities in order, and rebooted classic Mac OS into a (I believe generally successful) Aqua. And in later years, Apple as a whole has often been good about creating extra distance from the peloton even if there was no immediate danger of being overtaken. But not here. Windows lost its way, and perhaps even the memories of the darkness of the 1990s and the revival of the 2000s are now forgotten. Even if Liquid Glass was executed extremely well, macOS would still feel bereft of true evolution and care. I know there have been some slight improvements to window tiling and more recently Spotlight, but little of this betrays urgency or suggests a vision. Finder feels like it’s been abandoned for over a decade. AirDrop UI is worse in use than many of the file sharing interfaces that came before it. This common UI is stuck in the state of the art of display colour science that is out of the previous century : = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/mailbag-photoshops-focus-post/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/mailbag-photoshops-focus-post/1.1600w.avif" type="image/avif"> Just on the topic that is fresh on my mind : Why does Shortcuts feel like a toy in all the moments it shouldn’t, but few of the moments it should? Why does the keyboard customization situation feels so messy? Or, why are both macOS and iPadOS still stuck in the ancient way of thinking that menu bars contain all the app’s commands, when the modern approach is: it’s command bars that do, with menus containing only a subset? An innovative modern operating system would offer a universal API for command bars that any app that wants one could use – instead, apps invent their own with varying levels of success and UI quality, and automation tools cannot do much since nothing’s compatible. (This in particular is an example of an area where web apps started leading the way.) These are just some examples that come to mind. It’s true I have admired and been inspired by some work done on Apple TV and the Vision Pro, but we also have to acknowledge that designing for net-new platforms is in many ways easier than for legacy ones. 2. Back to Photoshop. In the Hacker News thread , at least one person from Adobe dropped in to comment, and one paragraph caught my attention: These changes were part of the Beta program. As far as I am aware the response there was not on the same level as this blog post. It’s not my intention to pick on this Adobe employee, and I am not aware of the specific of their beta program (although I have used Photoshop in beta for a few years). But from my experience, this is why beta testing fails in this regard: 3. Oh, and when I say “broken windows,” I’m not just being cute. Here’s an example of Photoshop’s “explore” halo that occasionally appears on top of another app just because I have Photoshop open underneath. And, there is nothing I can do in Photoshop to get rid of it: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/mailbag-photoshops-focus-post/2.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/mailbag-photoshops-focus-post/2.1600w.avif" type="image/avif"> I think there is something fundamentally very broken with Photoshop’s (custom?) window management, seeing how PS windows jump in front of other applications, or how PS breaks other apps’s mouse pointers. But that’s a story for a different post. #adobe #apple #bugs #interface design #nick heer #process People in beta programs might be more lenient and excited to experiment. For obviously broken small UI things, people will be more inclined to think “oh, they will surely take care of that in the polish phase.” In general, reports of smaller UI things are less likely than bigger functional bugs like “this is not working” or “this is really slow now.” You really have to encourage and reward and incentivize people to do that, and usually identify the right people first, too. Please excuse my directness, but Photoshop’s user interface has felt low-quality for at least a decade now. There are a lot more examples. It’s hard to expect people in the beta to flag small UI stuff – including literal broken windows – when the evidence all around them is that the company doesn’t care. Just because we all encounter interfaces doesn’t mean everyone knows how to identify the things and say the words and connect the dots, especially when it comes to generally undefinable and unmeasurable craft. Good UI is deep expertise . Just like you cannot research or data science your way out of fundamentally bad product decision-making process, you also cannot add craft through relying on your users to tell you. You need to foster this on the inside.

1 views

AI for Production

☕ Welcome to The Coder Cafe! These days, most posts about AI for production circle the same ideas: automated remediation, anomaly detection, alerting triage, etc. These are interesting starting points, but they share a common assumption: that AI’s job is to replace what SREs do. In this post, I want to explore the idea of having AI as a cognitive partner, something that extends what a single engineer can hold in their head at once. Get cozy, grab a coffee, and let’s begin! At Google, I’m an SRE on the  Google Distributed Cloud  team, where the infrastructure stack spans Kubernetes, Borg, distributed storage, virtualization, networking, and more. Over the past months, I’ve been experimenting with ways AI can help not only by automating work away, but also by reducing the cognitive overhead that makes production work quite overwhelming sometimes. Here are three directions that changed how I thought about the problem. In my team, we have hundreds of dashboards. Kubernetes clusters, Borg jobs, storage metrics, VM utilization, network metrics, etc. Each one tells part of the story. When something went wrong, and I wanted to understand the current state of the system, I needed to spend a significant amount of time opening tabs and cross-referencing panels to get a complete picture. This is a fundamentally human bottleneck. Each dashboard was designed to answer a specific question . The question “ What is the current situation? ” doesn’t map to any single dashboard, and navigating all of them to reconstruct an answer takes time we often don’t have. Interestingly, this is where AI can change the equation. Instead of navigating dashboards, imagine describing your system to an AI agent with access to your observability stack and simply asking: “ What’s going on? ” The agent queries across your telemetry data, picks out what stands out, and hands you back a coherent narrative , something you can actually act on. Like: “ This specific cluster has an issue with all the containers using distributed storage running on that specific node since 2h. ” This shifts the focus from navigator (opening dashboards one by one) to interpreter (acting on a synthesized summary). And that shift matters: every minute you spend navigating is a minute you're not spending on the actual problem. A few months ago, I was investigating a storage incident on a cluster. The failure itself was clear: a disk issue that surfaced as elevated latency and eventually a service degradation. What wasn’t clear was why it happened when it did. I used Gemini CLI to navigate the metrics data around the event window. What it surfaced surprised me: the root cause signals had been present in the telemetry hours before the incident triggered any alert. Subtle correlations across metrics that individually looked like noise: disk read latency creeping slightly upward, I/O wait ticking up on specific nodes, a minor memory pressure pattern. Together, they pointed directly at the failure that was coming. A human reviewing those dashboards in real time would almost certainly have missed it. Each individual signal was within an acceptable range. The pattern only became visible when we looked at all of them together, across time. This is what I’d call telemetry archaeology : using AI to go back through your metrics data and surface the correlations an alerting system wasn’t designed to catch. It’s worth being precise about what makes this different from anomaly detection. Anomaly detection tells you when something looks wrong. Telemetry archaeology is about finding the patterns that appear before anything looks wrong at all , relationships that no one thought to encode into an alert, because no one knew they existed until the incident happened. The practical implication is significant. If these correlations exist in your past incidents, they likely exist in future ones. An AI agent that continuously monitors for these multi-signal patterns could surface a warning (” This looks like the early stages of what happened last time ”) long before your system starts showing symptoms. Active incidents can be cognitively brutal . You can be debugging a live system, managing communication with stakeholders, coordinating with other engineers, and trying to remember what you checked 20 minutes ago, all at the same time. A common consequence is that the engineer with the deepest system knowledge gets pulled out of deep focus to write status updates, summarize what’s been tried, and maintain a running timeline. This work is necessary, but it’s expensive. Every context switch makes it harder to hold the full mental model of the incident in your head. And once that model fragments, rebuilding it takes time you don’t have. NOTE : This is actually one of the reasons Google developed the IMAG process, with clear role separation: The Incident Commander (IC) coordinates the overall response, the Communications Lead (CL) handles stakeholder updates, and the Operations Lead (OL) focuses on mitigating the issue. The explicit goal is to prevent any single person from being pulled in too many directions at once. AI can absorb most of this overhead . Think of it as a second brain that’s been in the room the whole time: it tracks what hypotheses have been tested, which ones were ruled out and why, what changed in the system during the incident window, and what hasn’t been explored yet. When a new engineer joins the investigation, instead of spending ten minutes getting them up to speed, you ask the AI for a summary. AI’s role here is handling the administrative layer of the incident: the parts that pull you out of flow, so you can stay in the problem instead of constantly being yanked out of it. I’ve been using AI this way during my own shifts. Even without a purpose-built tool, maintaining a running log with AI (e.g., what we’ve tried, what we know, what’s next) noticeably changes how an incident feels. AI is getting better every day. Are you? At The Coder Cafe, we serve fundamental concepts to make you an engineer that AI won’t replace. Written by a Google SWE, trusted by thousands of engineers worldwide. The common “AI for production” narrative focuses on automation and replacement; cognitive augmentation is the underexplored angle. Situation awareness: AI can synthesize across hundreds of dashboards to answer “ What’s the current situation? ” in seconds, shifting your role from navigator to interpreter. Telemetry archaeology: AI can surface hidden correlations across metrics that individually look like noise, revealing root cause signals that were present hours before any alert fired. Incident co-pilot: AI can absorb the administrative layer of an active incident (status updates, running timeline, hypothesis tracking), keeping the engineer in deep focus instead of constant context switching. None of this requires replacing the engineer. The value is in extending what one person can hold in their head under pressure. Reliability Resilient, Fault-tolerant, Robust, or Reliable? Lurking Variables Google Site Reliability Engineering: Incident Management Guide The future of software engineering is SRE At Google, I’m an SRE on the  Google Distributed Cloud  team, where the infrastructure stack spans Kubernetes, Borg, distributed storage, virtualization, networking, and more. Over the past months, I’ve been experimenting with ways AI can help not only by automating work away, but also by reducing the cognitive overhead that makes production work quite overwhelming sometimes. Here are three directions that changed how I thought about the problem. Situation Awareness In my team, we have hundreds of dashboards. Kubernetes clusters, Borg jobs, storage metrics, VM utilization, network metrics, etc. Each one tells part of the story. When something went wrong, and I wanted to understand the current state of the system, I needed to spend a significant amount of time opening tabs and cross-referencing panels to get a complete picture. This is a fundamentally human bottleneck. Each dashboard was designed to answer a specific question . The question “ What is the current situation? ” doesn’t map to any single dashboard, and navigating all of them to reconstruct an answer takes time we often don’t have. Interestingly, this is where AI can change the equation. Instead of navigating dashboards, imagine describing your system to an AI agent with access to your observability stack and simply asking: “ What’s going on? ” The agent queries across your telemetry data, picks out what stands out, and hands you back a coherent narrative , something you can actually act on. Like: “ This specific cluster has an issue with all the containers using distributed storage running on that specific node since 2h. ” This shifts the focus from navigator (opening dashboards one by one) to interpreter (acting on a synthesized summary). And that shift matters: every minute you spend navigating is a minute you're not spending on the actual problem. Telemetry Archaeology A few months ago, I was investigating a storage incident on a cluster. The failure itself was clear: a disk issue that surfaced as elevated latency and eventually a service degradation. What wasn’t clear was why it happened when it did. I used Gemini CLI to navigate the metrics data around the event window. What it surfaced surprised me: the root cause signals had been present in the telemetry hours before the incident triggered any alert. Subtle correlations across metrics that individually looked like noise: disk read latency creeping slightly upward, I/O wait ticking up on specific nodes, a minor memory pressure pattern. Together, they pointed directly at the failure that was coming. A human reviewing those dashboards in real time would almost certainly have missed it. Each individual signal was within an acceptable range. The pattern only became visible when we looked at all of them together, across time. This is what I’d call telemetry archaeology : using AI to go back through your metrics data and surface the correlations an alerting system wasn’t designed to catch. It’s worth being precise about what makes this different from anomaly detection. Anomaly detection tells you when something looks wrong. Telemetry archaeology is about finding the patterns that appear before anything looks wrong at all , relationships that no one thought to encode into an alert, because no one knew they existed until the incident happened. The practical implication is significant. If these correlations exist in your past incidents, they likely exist in future ones. An AI agent that continuously monitors for these multi-signal patterns could surface a warning (” This looks like the early stages of what happened last time ”) long before your system starts showing symptoms. Incident Co-Pilot Active incidents can be cognitively brutal . You can be debugging a live system, managing communication with stakeholders, coordinating with other engineers, and trying to remember what you checked 20 minutes ago, all at the same time. A common consequence is that the engineer with the deepest system knowledge gets pulled out of deep focus to write status updates, summarize what’s been tried, and maintain a running timeline. This work is necessary, but it’s expensive. Every context switch makes it harder to hold the full mental model of the incident in your head. And once that model fragments, rebuilding it takes time you don’t have. NOTE : This is actually one of the reasons Google developed the IMAG process, with clear role separation: The Incident Commander (IC) coordinates the overall response, the Communications Lead (CL) handles stakeholder updates, and the Operations Lead (OL) focuses on mitigating the issue. The explicit goal is to prevent any single person from being pulled in too many directions at once. AI can absorb most of this overhead . Think of it as a second brain that’s been in the room the whole time: it tracks what hypotheses have been tested, which ones were ruled out and why, what changed in the system during the incident window, and what hasn’t been explored yet. When a new engineer joins the investigation, instead of spending ten minutes getting them up to speed, you ask the AI for a summary. AI’s role here is handling the administrative layer of the incident: the parts that pull you out of flow, so you can stay in the problem instead of constantly being yanked out of it. I’ve been using AI this way during my own shifts. Even without a purpose-built tool, maintaining a running log with AI (e.g., what we’ve tried, what we know, what’s next) noticeably changes how an incident feels. AI is getting better every day. Are you? At The Coder Cafe, we serve fundamental concepts to make you an engineer that AI won’t replace. Written by a Google SWE, trusted by thousands of engineers worldwide. Summary The common “AI for production” narrative focuses on automation and replacement; cognitive augmentation is the underexplored angle. Situation awareness: AI can synthesize across hundreds of dashboards to answer “ What’s the current situation? ” in seconds, shifting your role from navigator to interpreter. Telemetry archaeology: AI can surface hidden correlations across metrics that individually look like noise, revealing root cause signals that were present hours before any alert fired. Incident co-pilot: AI can absorb the administrative layer of an active incident (status updates, running timeline, hypothesis tracking), keeping the engineer in deep focus instead of constant context switching. None of this requires replacing the engineer. The value is in extending what one person can hold in their head under pressure. Reliability Resilient, Fault-tolerant, Robust, or Reliable? Lurking Variables Google Site Reliability Engineering: Incident Management Guide The future of software engineering is SRE

0 views
Stratechery Yesterday

The Deployment Company, Back to the 70s, Apple and Intel

Listen to this post: Good morning, President Trump is on the way to China, and Sharp China is your go-to podcast for understanding what happens next. Add it to your podcast player now in anticipation of the next few episodes breaking down the trip. On to the Update: From Reuters : OpenAI said on Monday it is setting up a new company with more than $4 billion in initial investment to help organizations build and deploy artificial intelligence systems, and will acquire an AI consulting firm, Tomoro, to quickly scale up the unit. After its early models saw strong resonance with consumers, OpenAI has been working aggressively to sign corporate contracts and establish a large presence in the business world where its AI will see large-scale deployment. The venture, which will be majority owned and controlled by OpenAI, also comes as rival Anthropic enjoys strong success in its enterprise AI push with its Claude family of models seeing rapid adoption among businesses. The new firm, called OpenAI Deployment Company, will help the ChatGPT maker embed engineers specializing in frontier AI deployment into organizations that will then work closely with various teams to identify where AI can make the biggest impact, OpenAI said. Its acquisition of Tomoro, a consulting firm that helps enterprises deploy AI, will bring around 150 experienced AI engineers and “deployment specialists” to the new unit from day one. Tomoro was formed in 2023 in alliance with OpenAI, and counts companies such as Mattel, Red Bull, Tesco and Virgin Atlantic as its clients, according to its website. That was on Monday; on Tuesday, from The Information : Google plans to hire hundreds of engineers to help customers start using its business-focused AI products, according to a person familiar with the situation. Google’s new “forward deployed engineers” will form a new team within Google Cloud, the unit’s chief, Thomas Kurian, said on LinkedIn on Tuesday, without disclosing the size of the effort. Matt Renner, Google Cloud’s chief revenue officer, said in a separate post that the move would help Google “show up for our customers with more technical resources (vs just an ocean of salespeople).” The announcement is one of several in the industry in recent weeks as tech companies are deploying armies of humans—often described as “forward deployed engineers”—and partnerships with consulting companies to get customers using AI-driven technology intended to automate work. On Monday, OpenAI launched the “OpenAI Deployment Company” in partnership with consulting and investment firms. Last week, Anthropic announced the creation of a joint venture with private equity firms to sell its AI to the PE firms’ customers. It is, needless to say, tempting to drop some snark about AGI apparently not being good enough to deploy AI, but instead I’m going to go with “as predicted”. In 2024’s Enterprise Philosophy and the First Wave of AI , I made the case that the proper analogy for AI in the enterprise was not SaaS, but rather the first wave of computing in the 1970s. Agents aren’t copilots; they are replacements. They do work in place of humans — think call centers and the like, to start — and they have all of the advantages of software: always available, and scalable up-and-down with demand…Benioff isn’t talking about making employees more productive, but rather companies; the verb that applies to employees is “augmented”, which sounds much nicer than “replaced”; the ultimate goal is stated as well: business results. That right there is tech’s third philosophy: improving the bottom line for large enterprises. Notice how well this framing applies to the mainframe wave of computing: accounting and ERP software made companies more productive and drove positive business results; the employees that were “augmented” were managers who got far more accurate reports much more quickly, while the employees who used to do that work were replaced. Critically, the decision about whether or not to make this change did not depend on rank-and-file employees changing how they worked, but for executives to decide to take the plunge. Specifically, I don’t think that the Deployment Company is going in to help employees use chatbots; that’s even more clearly the case with the PE firms that both OpenAI and Anthropic are doing deals with. I expect there to be an ever-increasing number of deals where PE buys software firms with reliable cash flows and conducts significant layoffs, forcing AI to pick up the slack, solving stock-based compensation issues in the process. I don’t know if the mandate for the Deployment Company is going to be quite so harsh, but I assume this is a company that is hired by the executive suite to fundamentally rethink business processes in a way that hasn’t been done since the mainframe: Most historically-driven AI analogies usually come from the Internet, and understandably so: that was both an epochal change and also much fresher in our collective memories. My core contention here, however, is that AI truly is a new way of computing, and that means the better analogies are to computing itself. Transformers are the transistor, and mainframes are today’s models. The GUI is, arguably, still TBD. To the extent that is right, then, the biggest opportunity is in top-down enterprise implementations. The enterprise philosophy is older than the two consumer philosophies I wrote about previously: its motivation is not the user, but the buyer, who wants to increase revenue and cut costs, and will be brutally rational about how to achieve that (including running expected value calculations on agents making mistakes). That will be the only way to justify the compute necessary to scale out agentic capabilities, and to do the years of work necessary to get data in a state where humans can be replaced. The bottom line benefits — the essence of enterprise philosophy — will compel just that. What I wonder is how much of the work ends up reworking data; that, as I noted in that article, is why I was bullish on Palantir: That leaves the data piece, and while Benioff bragged about all of the data that Salesforce had, it doesn’t have everything, and what it does have is scattered across the phalanx of applications and storage layers that make up the Salesforce Platform. Indeed, Microsoft faces the same problem: while their Copilot vision includes APIs for 3rd-party “agents” — in this case, data from other companies — the reality is that an effective Agent — i.e. a worker replacement — needs access to everything in a way that it can reason over. The ability of large language models to handle unstructured data is revolutionary, but the fact remains that better data still results in better output; explicit step-by-step reasoning data, for example, is a big part of how o1 works. To that end, the company I am most intrigued by, for what I think will be the first wave of AI, is Palantir… That integration looks like this illustration from the company’s webpage for Foundry, what they call “The Ontology-Powered Operating System for the Modern Enterprise”: What is notable about this illustration is just how deeply Palantir needs to get into an enterprise’s operations to achieve its goals. This isn’t a consumery-SaaS application that your team leader puts on their credit card; it is SOFTWARE of the sort that Salesforce sought to move beyond. Google’s Kurian, by the way, did dismiss any sort of Palantir comparison in a Stratechery Interview last month: This all makes perfect sense, particularly this bit about the Knowledge Catalog definitely fits how I’ve been thinking. I wrote about this a few years ago about this importance of this whole layer and understanding it, it’s a bit of a big lift to get this in place. You have some sort of analog, say, with like a Palantir that’s putting in like their ontology thing. They have FDEs out on the site, multi-month projects doing this. You have OpenAI talking about Frontier, their agent layer, and they’re partnering with all the tech consultancies to build this out. Is this going to entail a lot of boots on the ground to get this graph working and functional in a way that your agents can operate effectively across it? TK: We’re not competing with Palantir, we’re not building a semantic dictionary or an ontology. What we’re doing is, today I’ll give you the closest analogy. TK: Today when you use a model, let’s say you use Gemini, and you ask a question, Gemini goes through reasoning, and then it shows you a citation. A citation is, “How did I answer the question and what’s the source I derived from?” Now imagine that citation was a query that needed to go to a folder in, for example, a storage system because there’s some documents there and a database because, for example, in a part number, just think about there’s a part number document that lists all the part numbers and sits in a drive and then that part number you need to fetch out to say it’s the modem that the guy is coming to repair, and that’s mapped to a table in a database. So what the graph does, we use Gemini, so we don’t need humans, we use Gemini to say, “Hey, go and read all these documents in these drives and extract the information from it and then match that to the database table that has the reference to the part number”, and so then when Gemini turns around and says, “I got this query about how much inventory of modems they are”, the first thing it does is it says, “Okay, go to the Knowledge Catalog and it says modem is part number one, two, three, four, five”, and then it says, “By the way the table in the database that has the inventory information about this part number is this table, here’s a SQL”, it then makes the quality of what we generate higher and then when it answers the question it shows back — back to your, “Trust my data”, it shows a grounding citation saying, “That’s where we got it from.” Well, so much for not needing humans! I joke, mostly — Kurian was referring to not needing a Palantir-like ontology, not necessarily dismissing the need for FDEs — but it sure is interesting how AI is creating the need for new kinds of jobs. It’s almost as if the world is more dynamic, and pure intelligence, unadulterated by what already exists and the burden of reflexivity, is more static, than the most pessimistic prognosticators may have anticipated. More prosaically, OpenAI and Anthropic need the revenue, enterprises need the imagination, and Google needs to stay in the game. From the Wall Street Journal : Apple and Intel have reached a preliminary agreement for Intel to manufacture some of the chips that power Apple devices, according to people familiar with the matter. Intensive talks between the two companies have been ongoing for more than a year, and they hammered out a formal deal in recent months, these people said. Bloomberg News previously reported the talks. It’s still unclear which Apple products Intel would make chips for, these people said. Apple ships more than 200 million iPhones a year as well as millions of iPads and Mac computers. Ming-Chi Kuo reported on X late last year that Intel would make Apple’s most basic M processor on its 18A process; he didn’t specify which generation. Regardless, while the Wall Street Journal cites Trump administration pressure, and an earlier Bloomberg article Apple’s concentration risk on TSMC and Taiwan, the most obvious reason for a deal — assuming it exists — is economic. Specifically, Apple has for two quarters running said it can’t satisfy demand because it can’t get enough capacity at TSMC. CEO Tim Cook referenced this point multiple times on the last earnings call , but I think this was the most important articulation: The constraint in the March quarter and the June quarter, the primary constraint is the availability of the advanced nodes our SoCs are produced on, not memory. And so I don’t want to predict for supply and demand to match because if I look at it realistically, I think on the Mac mini and the Mac Studio, I believe it will take several months to reach supply-demand balance. And so we’re not at the point where we’re saying this is going to end anytime soon. And it’s not because of a problem per se other than we just undercalled the demand. And there are lead times to this, as you well understand, and it takes a while to correct that. And the primary constraint from a product point of view, or the majority of it for this quarter, for the June quarter will be on the Mac. And it’s Mac mini, Mac Studio and the MacBook Neo. It’s all of those. Cook talked about lead times last quarter as well, and the important thing to note is that while it does take five months or so to make new chips, assuming Apple realized it needed more iPhone 17 Pro chips right away, those new A19 Pro lines only started producing chips partway through last quarter (which is why iPhone 17 Pro sales weren’t as high as they could be). Critically, however, what seems likely is that Apple took capacity away from the Mac to make more iPhone chips, and now doesn’t have enough chips for the Mini and Studio either. The long-and-short of it is this: Apple doesn’t have flexible access to TSMC capacity anymore, because so much of that capacity is going to AI in particular, and it’s costing Apple meaningful money across multiple product lines. This was always the thing that would bring companies to Intel; I wrote in TSMC Risk : Becoming a meaningful customer of Samsung or Intel is very risky: it takes years to get a chip working on a new process, which hardly seems worth it if that process might not be as good, and if the company offering the process definitely isn’t as customer service-centric as TSMC. I understand why everyone sticks with TSMC. The reality that hyperscalers and fabless chip companies need to wake up to, however, is that avoiding the risk of working with someone other than TSMC incurs new risks that are both harder to see and also much more substantial. Except again, we can see the harms already: foregone revenue today as demand outstrips supply. Today’s shortages, however, may prove to be peanuts: if AI has the potential these companies claim it does, future foregone revenue at the end of the decade is going to cost exponentially more — surely a lot more than whatever expense is necessary to make Samsung and/or Intel into viable competitors for TSMC. This, incidentally, is how the geographic risk issue will be fixed, if it ever is. It’s hard to get companies to pay for insurance for geopolitical risks that may never materialize. What is much more likely is that TSMC’s customers realize that their biggest risk isn’t that TSMC gets blown up by China, but that TSMC’s monopoly and reasonable reluctance to risk a rate of investment that matches the rest of the industry means that the rest of the industry fails to fully capture the value of AI. We’re already here (reportedly). TSMC’s failure to invest aggressively enough over the last several years will, in the end, give Intel the single most important thing it needs to become a viable competitor: the customer who did more than any other to make TSMC into the leader in the first place. This Update will be available as a podcast later today. To receive it in your podcast player, visit Stratechery . The Stratechery Update is intended for a single recipient, but occasional forwarding is totally fine! If you would like to order multiple subscriptions for your team with a group discount (minimum 5), please contact me directly. Thanks for being a subscriber, and have a great day!

0 views
Zak Knill Yesterday

LLMs are breaking 20 year old system design

The ‘cloud-native’ architecture of the last decade is built on a 20-year-old assumption: that state lives in the database, and compute is stateless. If you want to scale, you scale the database vertically (get a larger machine) [1] [1] or design the database schema around partition the data and you scale your application servers horizontally (add more boxes). Any request can hit any server, the loadbalancer doesn’t care, and the database is the single source of truth.

0 views
Ginger Bill Yesterday

The Aesthetic Problem of Namespacing

Karl Zylinski;s Tom;s Namespaces: An Odin Fanfic is an excellent exploration of the namespacing problem in imperative programming languages such as Odin I highly recommend reading that article before reading this one!. After sharing it on many comment forum sites, I;ve concluded there;s no real ;solution.; AssociationThe article uses a simple example:The aesthetic argument against this form of namespacing is that this looks fine with short 1/2 word length type names, but becomes unwieldy with longer ones like :The proposed fix ...

0 views
Evan Hahn Yesterday

Open Link in Unloaded Tab, a little Firefox extension

In short: I just published Open Link in Unloaded Tab , a little Firefox extension that adds “Open Link in Unloaded Tab” to the right-click context menu. In Firefox, you can unload tabs to save system resources. But there’s no way to open a new tab in the unloaded state…until now! I built a very simple extension that adds a new option to do this. (It even has a cute icon which I paid ~$15 for.) I’ve built one-off extensions before, but this is the first one I’ve submitted to the Firefox Add-ons directory. Download the extension here or check out the source code .

0 views
DYNOMIGHT Yesterday

What’s with all the slide decks?

News from the world of real jobs: Apparently, sometime between 10 and 20 years ago, it became standard for people to communicate by sending slide decks around. These slides are never presented. They aren’t intended to be presented. They’re born, they’re sent around, and they die. What? I stress, the question is not why (or if) people give bad presentations . The mystery is why everyone is using presentation software for communication that is not a presentation. Is it because we’re all dummies? I’m putting this theory first because I suspect that you, beloved readers, will favor it. True, if you ask people why they make slides instead of writing, they’ll usually say, “because nobody wants to read”. So there’s that. But I don’t consider this much of an explanation. Dummies though we may be, we’ve been like that a long time. If we entered the Slideocene 15 years ago, why then? Why not before? Did we get worse at reading? The Discourse seems to have decided this is true, but is it true, or just moral panic? Since 1971, the US has tested 13-year-olds to measure long-term trends in reading ability. This shows a slow improvement until 2012, then a slow decline, and finally a post-COVID drop. The declines seem too small and too late to explain our mystery. Since 2000, PISA has tested reading performance in 15-year-olds around the world. This shows a decline on average, but it’s smaller in rich countries and nonexistent in the United States. (It’s the same story for science and a bit more negative for math .) Among adults, data is scarce. Basic literacy is generally improving , and American time use data shows a decline in reading for pleasure from around 23 minutes per day in 2003 to around 16 minutes per day in 2023. But this seems to miss time people spend reading on their phones. So it’s unclear if people got worse at reading. It feels plausible that people now spend less of their adulthood grappling with complex written arguments, and so got worse at that. But there’s little firm evidence. Another obvious theory is that we now have computers and software and the internet. Without these things, it would be impossible to email slides to each other. This seems relevant! Yes, but we had those things for a while before slide culture really took hold. And think about the situation before computers. Photocopiers were ubiquitous in corporate offices by the mid-1980s, and mimeographs were around decades before that. If slides were really that great, people could have made them by hand. But no one did. Of course, making slides by hand is inferior. But it’s not that inferior. So slides can’t be that big of a win. And… that’s pretty much the end of the obvious theories. None of them are very satisfying. So let’s take a step back. Historically, how did the slide-as-document displace the memo? As best I can tell, this was driven by management consultancies. If you go back to 1960, they delivered detailed written memos. The memo was the product. They’d likely give a presentation as well, but that was a separate ancillary thing, likely done using flipcharts or chalkboards. In the 1970s, the memo was still the product, but consultancies started to enforce a top-down logical structure (the Pyramid principle ). Presentations shifted to acetate transparencies. Both memos and presentations often included hand-drawn graphics like the nine-box or growth-share matrices. In the 1980s, the memo was still the product, but presentations became increasingly lengthy and polished. Expensive computers like the Genigraphics started to be used to generate charts. The 1990s were when things started to shift. By then, PowerPoint was everywhere, and junior analysts were expected to create presentations themselves. Consultancies gradually started to notice that (1) clients didn’t always read the memos; (2) clients loved slides and passed them around long after the presentation was over; and (3) creating a memo and a polished presentation was a lot of work. They put more and more effort into the slides. McKinsey especially evolved towards treating slides as the primary product, and mostly stopped writing long memos. Other consultancies followed. During the 2000s, slides became even more ornate. Consultancies evolved their formatting rules, and created fancy data-dense charts. They learned that a 200 slide deck made clients feel like they got a lot for their money. Gradually, they oriented their entire business around slides. Projects would start with managers creating a template presentation with “ghost slides” and assigning different parts to junior analysts. Soon, this spread outwards, both from people who interacted with consultants and from the ex-consultant diaspora. People everywhere started thinking and communicating in slides, and now everything is slides, yay! That story makes slides-as-documents sound inevitable: People liked them, so they became popular. But there’s an alternative timeline in which we resisted the slide into slide maximalism. That timeline is Amazon.com, Inc. In 2004, Jeff Bezos famously instituted a no-presentations policy at Amazon. His logic was that slides hide poor reasoning and are a tool to persuade rather than inform. Instead, everyone involved with strategic decisions at Amazon needs to learn to write a six-page memo. Meetings begin with everyone sitting and silently reading one of these memos. Presentation software is not banned at Amazon. The ban is only for using it for internal meetings and decision-making. They use slides for external communication. There is no policy that prohibits someone from making slides and emailing them around. And yet, people don’t make slides and email them around, because it’s not part of Amazon’s culture. In effect, Amazon is a counter-movement. Most of the world decided that slides are good, because slides are easy. Bezos decided that writing is good because writing is hard. There are millions of articles explaining why Bezos’ policy is pure genius. They claim that constructing a narrative requires deeper analytical thinking and exposes flaws in logic. I want to believe those theories. I now realize they’re very similar to some of my arguments for why writing with too much formatting is bad. I’m not sure if writing is the secret to Amazon’s success. But Amazon is successful. This demonstrates that slide life is a choice, not technological destiny—institutions can choose writing over slides and flourish anyway. Warning: If you like your theories simple and mono-causal, you aren’t going to like this. Slides are a win, but a small one. The shift to slides wasn’t a “mistake”, it happened because people like it. But if sharing slides outside of presentations became illegal, this wouldn’t cause per-capita GDP to crash. That’s why people didn’t scratch slides into mimeograph stencils back in the 1950s. It wasn’t worth the modest effort. When computers and software showed up, it became easier to share slides. But people didn’t immediately shift to slides-as-documents because the win isn’t that big, because culture changes slowly, and because everyone had pre-existing skills for reading and writing documents. Consultancies happened to be in the economic niche with the strongest selection pressure to evolve towards slides-as-documents. So when making slides became cheaper, they shifted. Slowly, that norm spread outwards, people got used to communicating in slides, and here we are. Institutions can resist that norm and still be successful. If you take modern people and force them to read and write, they do just fine. Humans evolved to learn and communicate in a fragmented, interactive, and visual style. It’s hard to argue that any shift in that direction is a catastrophe. Except blogs. The decline of the blog must be arrested.

0 views