Posts in Programming (20 found)

Choose your own dark mode

Hello RSS reader! This post contains an interactive feature. Please visit the canonical web page for an optimal viewing experience :) When I redesigned my website earlier this year I removed dark mode . I never liked the colours, and the light switch toggle was so 2010’s . Personally I prefer reading with a dark theme for long-form content. Dark is not my brand though and I don’t believe every website needs to support colour scheme preference automatically. A good browser has reader mode, I use that all the time. But what if I let my readers decide on a dark colour scheme? Below is a colour picker doohickey that should let you experience dark mode (on this page only). I’m testing in production (for reasons) so if it’s broken come back in an hour, or update your browser. It uses the native colour input which sucks in every browser. ⚠️ Warning: expect a sudden and dramatic colour shift. Try not to flashbang yourself. This is just an experiment so your colour choice will not persist. If you want to keep it, like and subscribe and @ me on the socials. Use your preferred hex code as a hashtag. Here’s how my homepage looks with a dark blue scheme. I reckon the duotone effect works much better than trying to invert my brand colours. Thanks for reading! Follow me on Mastodon and Bluesky . Subscribe to my Blog and Notes or Combined feeds.

0 views
Stratechery Yesterday

IBM Misses, IBM’s Mainframe Moat, IBM’s Many AI Problems

IBM announced preliminary results that spooked the software market generally; this is a story, however, specifically about IBM and its mainframe franchise.

0 views

How to stay in the coding flow using LLMs

We all know that moving to LLMs and agents has caused the feeling of losing touch with parts, or maybe even all, of a code base. This isn’t just something that is problematic for managing and handling the translation from business logic to implementation it is a problem because it feels exhausting . I’ve had coding sessions that lasted 12 hours and afterwards felt great. Meanwhile I’ve done LLM prompting for a few hours and felt exhausted or unsure of what I did. Lately I’ve been keeping this in mind and have been looking for a few ways in which I can maintain a flow state and take advantage of LLMs. Remember back in 2025 when this was the default way of using them? I actually still find this to be my preferred way. Using LLMs with code harnesses in projects injects so much unnecessary information that asking simple questions gets out control. For example, here I’m exploring some data, and I wanted a quick regex, I turned over to my VSCode chat window, and forgot that it was an agent, and asked it the question. It proceeds to start looking at the files, wanting to run code etc. All off target of what I need . So next I switched VSCode to “Ask” instead of agent, again the LLM is flooded with context about my project and proceeds to output a massive amount of distracting and off topic code suggestions. Switch to a browser chat window which has little to no context about what you’re working on and ask it my specific question, boom it spits out a few quick regexes for my Python list comprehension that are exactly what I need . Is this bad advice? Well, maybe. But was this what you’re already doing, definitely. But the point here is to multitask coding on more than one thing at a time. I’ve found that this keeps me in the flow state much better than if I let myself browse the news. So instead of switching from your agent -> browse social media switch between multiple projects. This depends on how your code / work is structured, but depending on the scope this means either switching between several agents in the same project or having several projects open at once. Types of positive multitasking to stay in the zone: For me, working on AppGoblin’s free ASO and mobile app ecosystem data , I have certain areas that *I* need to understand what is happening, for those reasons I do not let AI write anything more than boiler plate code. The clearest example of this I can give is SQL, where a lot of my most important relational logic exists. Sure, I can let an LLM one shot a complicated SQL and it will “work” but come weeks (or months!) later and I’ll find a complicated bug that slipped in. It’s not even necessarily about who was right/wrong in this situation, it’s that *I* need to know what’s going on in certain parts of the codebase. Something that ‘looks fine’ is a terrible feeling that later it was not what I wanted. This last one is probably best suited for other data crunchers out there, but it’s where I find a great sweet spot for staying in the zone. My favorite way to write code has always been to write code in an editor and send line to a REPL. This is also more or less how SQL gets written as well where you build queries in your SQL editor by slowly making changes to the data, checking values / assumptions and eventually getting to your final SQL query. With the LLMs, I find myself using this flow lately: It’s more or less the same as I did before, just a lot less writing and let’s me hold onto the difficult concepts longer. If you’re actually in the flow of editing code, the best way to augment your coding is with code completion. I’ve found this to be the most powerful in that I don’t even have to start letting my mind wander for how to do some boiler plate code, it just pops up automatically. I love this because it helps me think at a high level in the code without the distractions of trying to remember how to do something when the how is not the important part. Probably the only issue with this is that code completion can be quite annoying and distracting in some situations. For example, writing free form and handling imports at the top of a file are examples where LLM ‘helpful’ code completion is just not helpful. If you enjoyed this feel free to share. Working on related projects File and project cleanup. LLMs generate many extra files and code and it’s best to stay on top of that yourself. Go through and delete extra files. Try asking LLMs for advice on what to remove, but do be careful with this idea. Tell LLM to write new code for processing data Step through the code my self line by line, checking the hotspots where I know assumptions / tricky data might be

0 views
Unsung 2 days ago

“Cursed knowledge we have learned that we wish we never knew.”

Immich is a self-hosted photo/​video app, and one of their side pages is Cursed Knowledge : Cursed knowledge we have learned as a result of building Immich that we wish we never knew. = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/cursed-knowledge-we-have-learned-that-we-wish-we-never-knew/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/cursed-knowledge-we-have-learned-that-we-wish-we-never-knew/1.1600w.avif" type="image/avif"> There is something about this format that I really enjoyed as a reflection but also as a way to share with others – simple one sentence/​paragraph updates with links, so you can inhale quickly but also go deep if needed. There’s some overlap with bugs here, but it’s not necessarily only buggy stuff – also quirks of formats, observations, etc. I made a cursed knowledge page for Unsung – let me know! (Thanks to Casey Gollan for posting about the original page.)

0 views
Martin Fowler 2 days ago

DSLs Enable Reliable Use of LLMs

LLMs generate code incredibly fast, but to ensure they generate exactly what is intended, they need clear boundaries. Abstractions and Domain-Specific Languages (DSLs) provide a strong harness that guides LLMs right from the start. Unmesh Joshi describes how the example of Tickloom - a domain model and DSL for illustrating distributed system behavior - shows how we can use an LLM as a partner to iteratively build a DSL and as a natural language interface to use it. Such a DSL can act as the key source of truth for software systems in the world of LLMs.

0 views
annie's blog 2 days ago

I have no idea who celebrities are anymore

Julia Roberts? She was in that one movie with that guy, and the other one with the other guy, and like 100 more. Whatever. But she’s old news. Like all the other celebrity names I actually recognize, which isn’t a lot, but is some. Just a minute ago a headline floated by: Person A is doing Thing with Person B, what will Person C think? I have no idea: Who the people are, their relationship or lack thereof, their various claims to fame. I do not possess any crumbs of context helping me interpret the situation or nod knowingly about what C’s thoughts will be. I Got Nothing. Which is fine. Preferable, even. I’ve never been a very good fan, it’s just not my thing. But cultural knowledge always seeps in. You just know some stuff like who’s famous and why, and you even have some sort of opinion about them. Until you don’t. I have reached the don’t point. It’s peaceful here.

0 views
Steve Klabnik 2 days ago

Too many words about DIDs

Your “Bluesky account” is not just a Bluesky account: it is an account that can be used with a variety of other applications. This post is going to be an exploration of part of what that means from a technical perspective, so if you’re not a software developer, this post isn’t for you. But what I’m going to explain is the technical mechanism for how your account works separate from Bluesky, and in fact, separate from any particular app. Let’s talk about identity: who are you, anyway? Users of a system need some sort of way to describe who they are to use it. If you want to log in, you need to present who you are. If you want to make a post, well, we need to know who the author of that post is. For atproto, the protocol that underlies Bluesky and other apps in the ATmosphere, they use the “Decentralized Identity” standard, also known as DID. The W3C standardized DIDs in 2022 . As you might guess from the name, DIDs are, an identifier that you can use as the basis of identity for building applications. And the idea is that these identifiers are decentralized. However, a lot of people have a lot of feelings about that specific word, and often accuse atproto of not being properly decentralized. We’re going to go over the details so you can understand how this works, and you can decide for yourself if this approach suits you or not. Here is my DID, we’ll use this as an example: There are three parts, separated by colons: The scheme ( ), the method ( ), and the DID method-specific identifier ( ). To use a DID, such as , you resolve it into a DID Document A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. That document contains various properties that describe the identity. Here’s my DID Document, at the time of writing: This document gives you everything you need to know to determine who I am, that is, given an arbitrary post that claims it’s written by me, this document describes how you’d verify that claim. We’ll get into how to do that that in a moment, but first, how do you resolve that DID into that DID document? Well, it’s pretty easy: each method is a standard that describes how you do that. So when you see , that means we use the PLC standard, which we’ll be going over in a moment. Another method supported by Bluesky is . In that case, you wouldn’t use the PLC standard, you’d use the Web one. This is the sense in which DIDs are decentralized: when you present your identity, you get to decide what method validates that that is a real identity. There’s no centralized authority that determines which DID types are valid. Now, of course, that doesn’t mean that every application supports every DID method, because while this specification is very generic, you’re still going to have to write some code to implement that particular method. I could say “Hey I’m ” and unless your app supports the method, it’s not gonna inherently just know what to do. So that is one important caveat. Let’s explain this resolution process for the method. While supported by Bluesky, a very small number of users actually use , but it’s a simpler method and so I think it’s illustrative to go over first. I’ll be using Liz Fong-Jones account as an example here. Her identity for that account is . So how do we resolve this DID into a DID Document? We take the method-specific identifier, which in this case is , and put it into this URL template: You can then go fetch this URL to resolve it into the DID Document, which at the time of writing, looks like this: This is very simple! So why might we not want to use ? Why bother with any other system? Well, this relies on the DNS system. One could make the argument that ultimately, this is still centralized in some form. If Liz’s domain registrar were to take away her domain, she would also lose control of this DID. In a more generic sense, if Liz decides she wants to not use that domain anymore, she will lose control of that identity to whoever does. That could be through non-malicious means, like letting it expire and someone else purchases it, or through malicious ones, like a hack which would compromise her registrar account and take the domain over. Also, you need to have a web server running on that domain with infinite uptime; if the server goes down, so does your ability to get the document. When this DID document changes, there’s no mechanism for clients to know that it’s changed, which means applications may use one that’s out of date, or that there is lag between updating the document and updating the application built on it, which may cause temporary problems until the latest document is fetched. All of these drawbacks led Bluesky to develop their own DID method, which attempts to fix these problems and others. This method is called . To resolve a , you take the entire DID, and put it in this template: You can then fetch that URL and get the DID document. So… what’s the difference? Well, in this case, both nothing and something. In a very literal sense, both are resolved in the same way: you fetch a URL. However, the details matter. There is already two ways in which this is different than DID:Web: I’ve presented the above as pros, but there are also cons. Before, I had to trust the DNS system and domain registrars, now I have to trust plc.directory. All of the same caveats apply in that sense, I have to trust that they don’t take my ID away from me, or that it doesn’t get stolen, etc. However, there are also some important details that mitigate this, which we’ll get to. But for some people, neither trusting DNS nor trusting plc.directory is acceptable, and there are other DID methods that use, for example, a blockchain to resolve the name. Bluesky does not support using any of those DID methods, so for this application, it’s not really relevant, but it’s important to know that they exist. Why do it this way? Well, the simplest way to put it is this: setting up a involves a lot of “nerd stuff.” You have to register a domain, and that’s also an ongoing monetary cost. You have to know how to set up a web server, and author some JSON to put on that server. You have to keep it running. You have to know how to store your private keys, and keep them safe. It’s a non-starter compared to “sign up for this web app.” And Bluesky’s goals involves making this platform accessible to non-nerds. By having plc.directory manage all of this, we eliminate all of those steps. While drafting this post, I have also been made aware of , which expands on and attempts to rectify some of its shortcomings. I have not read the spec yet, but it has reached 1.0, so it is probably worth checking out. I wanted to get this post shipped last week, and didn’t want to delay it further by adding another section, but if I were writing this post in the future, I’d probably want to talk about it as well, so just a little heads-up there. But it does also mean that, in some sense, Bluesky still owns your identity. They’ve generated a keypair for you, and the have access to the secret key. That’s unacceptable for some people. So how do you fix that? Well, has some additional features that does not. For example, will allow you to register additional keypairs with your ID and use them to rotate your signing keys. This allows you to remove the Bluesky generated keys and insert your own. While that is true, it’s also the case that your PDS needs to use your keys to sign your posts. As such, most people are likely to store their keys in their PDS, and so if you are using a Bluesky managed PDS, well, you’ve uploaded your keys to their infrastructure, and that’s probably not acceptable if you’re trying to keep your identity away from Bluesky. Of course, the solution there is to run your own PDS and then rotate your keys. At that point, your key is living on infrastructure you own, and Bluesky has no say over it any more. I think that this possibility is an important design property, and allows motivated users to meaningfully own their identity. A criticism of this boils down to “well, most users won’t do that,” and while that’s true, I also think that’s okay for most people, and that having the choice is more important than forcing every user to deal with their own key management. This is kind of an abrupt end to this post, but I just wanted to get some things down ‘on paper’ as it were. I hope you’ve learned a bit about identity and how it works with atproto. Here’s my post about this post on BlueSky: Too many words about DIDs: steveklabnik.com/writing/too-... Too many words about DIDs Blog post: Too many words about DIDs by Steve Klabnik Your DID is no longer tied to a specific domain name. I can let expire and move to and my stays the same. While a web server still needs to be running, that’s the job of plc.directory, not my own job. This is operationally much simpler.

0 views
Unsung 3 days ago

More absolutely strange Google shortcuts

I’m endlessly confounded (as a user) and fascinated (as a designer) when it comes the shortcut conventions in Google’s professional web apps. They seem… bad, but bad in a strange, inexplicable, enthralling way. Previously , we encountered this: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/more-absolutely-strange-google-shortcuts/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/more-absolutely-strange-google-shortcuts/1.1600w.avif" type="image/avif"> The lessons there were, primarily: don’t… do this, and also maybe don’t show it like this. Today’s entrant, from Google Drive, offers a different lesson: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/more-absolutely-strange-google-shortcuts/2.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/more-absolutely-strange-google-shortcuts/2.1600w.avif" type="image/avif"> Immediately, I have so many questions. Why a sequenced shortcut instead of something simpler, in a space where there aren’t that many shortcuts? Why Control of all things? On a Mac? Why is it so different than Google Docs in every way – don’t you all talk to each other? And why not a proper typographical symbol for Control (^ is not ⌃)? But there is also a mechanical lesson here. I’d encourage you to actually press any of these three shortcuts, and watch your fingers doing that. I bet you will observe one of two ways: Turns out, people are messy when it comes to modifier keys. That messiness was even encouraged from the very first day we breathed life into the very first modifier key. Most of 20th century typewriters had a full stop and a comma on both shifted and unshifted positions – pressing Shift was heavy early on, and this helped when punctuating all-caps sentences or preparing for a capital letter starting the next sentence. (Also, Shift Lock wasn’t as smart as Caps Lock is.) = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/more-absolutely-strange-google-shortcuts/3.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/more-absolutely-strange-google-shortcuts/3.1600w.avif" type="image/avif"> But even without that encouragement there are still two legitimately valid ways to understand “^C then F” – you release ⌃ before the second key, or after – but Google Drive only listens to the first one. Couple this with giving you zero feedback after ⌃C, and I won’t be surprised if many people try this sequence once, and give up assuming it’s just not working. So, it feels it’d be good to think about being extra forgiving here, the same way it’s good to think about “coyote time.” As always, please let me know if you see the method in this alleged madness . After all, the goal for this blog is not to blindly ridicule things, but to learn together through thick and thin. #google #keyboard ⌃ down, C down, C up, ⌃ up, F down, F up ⌃ down, C down, C up, F down, F up, ⌃ up

0 views
Martin Fowler 3 days ago

Fragments: July 13

Some more of my notes from Thoughtworks Future of Software Development Retreat . When we had our first retreat in Utah early this year, nobody had heard of Harness Engineering . This time we had a whole session on it. When comes to the guide side of harnesses, most of the discussion is about context management. While context windows have increased is size as models get more sophisticated, that doesn’t mean that models will properly focus on the right bits. Models typically only focus attention on part of the context, and to get the best behavior, we need to manage that focus. One attendee keeps their context small, limiting the file to less than 200 lines On the sensor side, we see more attention on computational sensors. Two patterns from one participant was shifting to languages with greater controls, (eg Rust rather than Python) and “leveling up” validation approaches, using more property-based testing and techniques from formal methods. One commented that while they aren’t smart enough to write specifications in a formal specification language, they are smart enough to read it and check it makes sense for their domain. Will our attention on harnesses last long enough for our next retreat? Will the models just get so good that harnesses become unnecessary? Those with some mechanical sympathy for LLMs seem to think not - but are they overly coupled to the current state of technology? I find such speculation tends not to lead anywhere useful, I’ve not seen much success in guessing the future in the past, and with technology as radical as this, I don’t see it being any easier. So for the moment, attention to harnesses pays off. We find it reduces token usage, and also allows weaker models to be useful, supporting such things as local hosting of open-weight models. ❄                ❄ Which naturally segues me to a session on self-hosted models. Increasing token costs have made hosting an open-weight model more attractive, particularly due to the decreasing time for open-weight models to catch up with frontier models. Cost isn’t the only factor, however, many folks find a desire to be independent of the frontier model firms to be the the driving force. After all we’ve seen the U.S. government intervene to deny access to models, increasing the desire for greater model sovereignty. Information security is also something to consider, some attendees just can’t give models necessary data for critical work. Even without that, if someone else hosts the model then their model learns rather than your model. And although recent events have increased interest, several participants worked with companies that had been self-hosting for up to a couple of years. Is this trudging down the same path of self-hosted clouds, which led to lots of folks spending excessive funds on half-arsed private clouds ? The answer hinges upon whether it ends up being simpler to host a model than a cloud, perhaps due to a simpler interaction protocol. The hard part of this may be the talent required to efficiently use the GPUs, managing an inference data center currently isn’t a widely available skill. Even self-hosted models are a cost to operate, capital costs in GPUs, ongoing costs in electricity. The physical design of a data center can affect optimal usage. There’s an opportunity here for professional services firms to help companies manage this. Cost control also involves teaching people to pick the right model for the job. Can we teach engineers, or indeed other users, to pick a less-powerful model? This, of course, could be a job for model itself, acting as a broker, deciding which model is the best choice to tackle certain jobs. Self-hosting may lead to a greater use of fine-tuning. Currently that’s a niche activity, but over time we could well find that models that are fine-tuned to a particular domain need less reasoning, consume less tokens, and thus are cheaper to operate. We are seeing models trained specifically to support programming. As with any topic with this degree of uncertainty, the big win isn’t finding the right answer, but coming up with a strategy that will cope with the inevitable and unpredictable changes. ❄                ❄ After an event like this, many people come up to me and ask me to make some grand summing up. I hate this, because I rarely leave these kinds of event with some grand narrative. Even after mulling on it afterwards (in writing the above notes) I still usually don’t have one, and distrust one that forms, as my skepticism includes attempts to make coherent narratives of an event that’s naturally rather jumbled. However my failings are irrelevant this time, because Kief Morris has put together such a narrative, and it’s a convincing one , even to a narrative-denier like me. The sessions had different titles and different casts, and on the surface they were about different problems. But they weren’t. Nearly every one of them was a different facet of the same argument. How much do we let an agent decide, and how do we stay confident in what it does? He looks at code review, questions whether it matters, but sees that the rigor that many associate with code review shifts to other forms. He describes the disagreements about how much we should trust an agent to identify and fix production incidents. He sees that the contrast between how much leeway teams give to agents depends on the context they are operating Underneath all of these sessions, the operations debate, the wide-remit team, the dark-factory spectrum, the argument about who’s allowed to steer the model, people were making the same handful of choices over and over about a single thing: the unit of work they were prepared to hand to an agent. How big it is. How much of the job it covers. What you do to get it ready to hand over. How you check what comes back. What you put around the agent to keep it inside the lines. Different rooms set those differently, but they were setting the same controls. ❄                ❄ Sam Ruby convened a session called “Bring me a Rock”. The name evokes a particular kind of management dysfunction. The manager tells his underlings to bring him a rock, and then starts rejecting the results without explaining why (“no not that one”, “no not that one”) until eventually one rock matches the unstated expectation. It names a manager who substitutes serial rejection for the work of saying what they want, and makes you pay for their unfinished thinking one rock at a time. Sam had already written why he thought with LLMs, this changed from a slur to a defensible way to work . When its a bunch of tireless machines with endless patience, that return new rocks in minutes rather than days, then an approach like this (using the brainstorming register becomes a defensible way to work. Sam described the discussion : The room pulled it somewhere narrower than I’d framed, and the narrower place was the more interesting one: not how to explore by elimination but who should even be allowed to. Product managers, increasingly people managers, are reaching for these models directly, and seasoned engineers get measurably better results from them than untrained people do — so the worry followed. If expertise is what separates a good outcome from slop, should non-engineers be steering the model at all? It’s a fair question, and I think it’s the wrong one, because it mistakes the act. When a manager reaches for an LLM instead of routing the work to the team that reports to them, they didn’t pick up a tool — they made a hire. And you don’t ask permission to manage your own team; a manager who decides a piece of work is better given to a new participant than to the existing one is doing the most ordinary thing a manager does. Framed that way, the permission question dissolves into an older, better-understood one — the one Drucker named in 1959: when the worker knows more about the specifics than the manager does, you manage by objective, not by method. The non-engineer steering an agent is exactly that manager, out-known by the thing they’re directing, and the slop the room feared is the old danger of managing by method when you should be managing by objective. The question isn’t may they hire? It’s do they know how to manage by objective? — which you can teach, hire for, and hold people to without anyone first becoming an engineer. Sam’s article explores managing an LLM by objective, giving it a goal rather than a task. And Kief’s earlier point about the essence of the discussion still holds: how confident can we be that it’s done the right thing? We can outsource many things, but not the acceptance criteria, at some point there’s a human request and a human judgment on whether that request was properly executed. But the danger lies in important unstated objectives, unstated perhaps because they weren’t even imagined. It’s easy to state objectives around desired functionality. Give me a an application that will examine my emails and form a todo list for today. But behind that simple statement is a thicket of unstated assumptions. We tend to assume The Genie won’t include any undesired functionality, perhaps deleting emails it thinks are unworthy of our attention. We assume it won’t let an email tell it to send private information to [email protected]. We have some hope here - we hear more experiences that suggest that recent models can do an excellent job of finding (and hopefully fixing) security holes. The careful precision of the machine outruns the sloppy if imaginative thinking in squishyware. Perhaps we can assume the genie can take care of some of our unstated objectives. Conformance tests (sensors) are more valuable than specifications (guides), but it’s hard to imagine all the conformance tests that are needed to say what shouldn’t happen. Furthermore, building software is about exploration, finding out how a workflow can evolve as machines are embedded in the process. For a human to guide that process, we need some understanding of it. My sense is that model building is still important, and while I agree that the genie can take an active role in that construction, I don’t think the human can entirely outsource it. Even if the genie builds the model itself, it needs to teach us that model, because the model helps us imagine and communicate the goals, the objectives that we give to the machine. ❄                ❄                ❄                ❄                ❄ If you follow my feeds (which you probably do if you’re reading this), then you’ll know that Birgitta Böckeler has written a couple of memos on working with local models. She first looked the factors that influence how viable they are for programming , and then related some of her recent experiences evaluating such models . As a nice, if accidental, complement to these, Sebastian Raschka wrote a detailed guide to his local model environment . Like Birgitta, he’s found the Qwen 3.6 model to be the current sweet spot for local agentic programming. ❄                ❄                ❄                ❄                ❄ Simon Willison shares a useful tip to save money while using the latest Anthropic Fable model Tell Fable to use other models for smaller tasks, applying its own judgement about which model to use. ❄                ❄                ❄                ❄                ❄ Josh Comeau writes a blog and online courses for developer education, primarily front-end web material. His been successful for most of this decade but has found his online courses have had only ⅓ the sales this year . He attributes this to AI, partly as people worry if it’s worth spending money on a job that may not have a future, but also because AI can provide personalized tutoring. ideally, it shouldn’t cost any money to learn stuff. But I sorta worry about how this is supposed to work, going forwards, if there’s no incentive for people to make high-quality free content. I’ve spoken to a few course creators now, and we’re all seeing the same trend. Revenue down 50%+. Fewer people engaging with our content. People switching to LLMs, which slurp up all of our work and regurgitate it, without consent or compensation. It feels pretty bleak. 😅 ❄                ❄                ❄                ❄                ❄ John Gruber is annoyed that Claude’s desktop app for MacOS in uses Electron . Electron guarantees that an app feels just as wrong on all platforms. He has some tasty invective for the folks at Anthropic with ties to the Electron platform. Finding out that one guy — who is a senior Electron maintainer — has led the teams for the desktop clients for Slack, Notion, and now Claude is like discovering that it was one guy — whose family business was a distillery — who helmed the Titanic, piloted the Hindenburg, and then served as air traffic controller for Amelia Earhart. The deeper question here is whether there should be a future for cross-platform front-ends in the world of agentic programming. There’s lots of evidence that coding agents do a great job of building the same thing in multiple languages and platform ecosystems. That should mean that the days of least-denominator cross-platform UIs are numbered - and that number is small. ❄                ❄                ❄                ❄                ❄ Dan Davies tries to draw a distinction between interactional and contributory expertise . Contributory expertise is that held by people who are doing the work to advance a field of study, interaction expertise is held by folks that spend time talking to contributory experts, building up a decent store of knowledge themselves, but not steeped in the day-to-day of the work. it seems to me that there is an important distinction here, which is not any less important because the dividing line might be difficult to establish empirically, or even if that line turns out to be in a different place from where we guessed it was. As well as difficult cases where it’s not clear, I think we could also come up with cases where the distinction between interactional and contributory expertise would suddenly become very clear and important indeed – the ones where someone who was faking it got “found out”. And so the question that I think is quite important is whether there is a similar kind of distinction between the kind of expertise that it’s possible for a machine to get by industralised consumption and interaction with a much larger corpus of literature than any human being could inhale, and genuine contributory expertise that could apply to entirely new situations outside that literature. As a human, I’d like to think I’m more of a contributor than an interactor (especially given my increasing introversion), and thus relatively safe from being forced into obsolescence by silicon. But I’m also aware that my career is devoid of any original ideas, my skill is only that of someone who is good at selecting and explaining the ideas of others. (As Brian Foote put it more memorably: “an intellectual jackal with good taste in carrion”.) But there’s skill in being a good jackal too - and we don’t really know yet where the real boundaries of the LLMs will lie.

0 views
<antirez> 3 days ago

Control the ideas, not the code

Look at the past history of this blog. There are many blog posts about programming with AI, a few of them date back to January 2024 (like this: https://antirez.com/news/140). I’m a relatively well regarded programmer, after all. I don’t have the need to still be in the “loop” as a old man that seeks for relevance, I recently rejoined Redis, and now I also am developing a new open source software for local LLM inference that received a good welcome in the community. Why I keep doing this, of saying what people don’t want to hear? Why I keep announcing how future programming will be by default? Because I feel the urge of lowering the impact for people less prepared to the change than me, often younger than me, and that, unlikely me, didn’t see many of those things coming (In 2022 I published, before ChatGPT existed, a book preannouncing many things that now happened and other things that I believe *will* happen, so I feel like I can say this without sounding egocentric). So mine is a trick. People feel more and more programming is completely modified by AI and don’t know what they should do, if they can really start coding in a completely different way, without looking much at the code as their main output. They feel like they are betraying their own field. So my intention is to arrive and say “look at me, In can write code, you know, I’m not hiding behind AI: yet, things changed, it’s not your weakness, it’s not that you are AI-pilled. It is just that our field is evolving in an incredible *and* painful (but also joyful) direction”. This is why yesterday, on X, I said that I believe many programmers at this point have less impact they could have because they look at the code. I truly believe into that. And note that this does not mean to vibe code something just asking for the final product. The point is: if you control the ideas of your software, looking at the code itself is suboptimal and often pointless. For the following reasons: 1. You can now generate a lot of code, even *not* accounting for the LLM code verbosity (that is also effect of not being able to instruct them well, for most of the part). How are you supposed to review 5k lines of code every day? 2. LLMs are very good at writing locally optimal code, and are worse (but improving) with big ideas. What’s the point of scanning function by function, line by line? Instead you should prompt the design you have in mind, sometimes ask “how is exactly the design of that part? How does it work?”, and evaluate if it is the right model. It is much faster. 3. The working day is 8 hours. If you read the code, it is a tradeoff. You are doing less of what today is the most important part of your job, that is, asking yourself: what I’m doing with this software? What are the new directions I want to take? And also, think at new ideas, features, optimizations tricks. And doing a lot of QA. Controlling the ideas. Do you remember this phrasing from the Mythical Man Month? Well, a book from the 70s tells us more things about the current software era than many of the things that were said from 2000 to 2020. Why people that now protest against AI were not horrified by the state of software in the last decade? The level of slop we touched during recent years, before AI, is unbelievable. I’ll say you another thing. What is slop? With DwarfStar I implemented an inference for two LLMs (DeepSeek v4 and GLM 5.2) in a completely automated way, but: try it yourself, you will discover you can’t just say “implement XYZ” and see it working. You have to understand how things work, what is the best design, how to reach a certain level of performance. Then I compared the implementation, for correctness, to other systems, finding that other implementations sometimes contained more errors. I researched more, and found that the local inference world is full of subtle errors that accumulate and damage the model output, issues in the attention implementation causing performance slopes after the context is over a certain limit because indexed attention implementations are broken (do more work than they should, for instance), and so forth. This is the result of a domain that is very complicated to handle, fast changing, with models that are slightly different one from the other in the inference graph being released every day. It’s an unfair game for developers. Well: AI helps a lot with that. There are many domains where rigorous engineering (in the design side) and testing is *far* better than writing a GPU kernel by hand (or reading it). So are we sure most of that resistance it is not ideological? Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. Yes, I do, but this is, at this point, something I *need* to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is *far worse*, and not since they are not good coders, but because it is a matter of taste. I write very clean code since I want it to be readable, so during the implementation of Redis Arrays I operated changes. I’m doing it again for the 50% memory saving optimization of Redis sorted sets, a PR that I’ll submit soon. But I do not feel this is useful anymore. Nobody should anymore look at this code, but only at the ideas the code contains. I continued to do it out of respect for users. Redis is at this point a commonly useful thing, and many programmers will open files and modify stuff by hand. But if I had my hands free, you know what I would do, instead? Use all the time that the review is taking me to do more QA, to think at the next optimization idea and apply it, and to use LLMs to write a DESIGN.md file where each data structure is described in human language, with the ideas it contains, the implementation tricks, the design. That, in the future, is going to be much more useful. Do you want to modify sorted sets? You open the file, read the design, then you own the ideas. You can open your agent and ask it what to do with the right mental model. This is a lot more useful than reviewing the code. Fable and GPT 5.6 reviews to the sorted sets memory saving are going to spot ways more errors and subtle race conditions that my review is going to uncover. Yet I’ll do it. But for the majority of software projects, all this does not make sense anymore. Focus on controlling the ideas, instead. Focus on quality, testing, and having an idea of the software you want to ship. The world changed and it is painful, but also full of opportunities to improve a software world that was already completely rotten. I have a doubt only regarding young programmers that don't have enough experience, and can't build a mental model. We don't know, yet, if they will require or not to understand very well how a given piece of code works, but I believe they should learn how to write programs. Yet, I'm not sure checking the LLM output is the right thing they should do. It may be a lot more useful if they learn some programming language and implement a small interpreter, a small database, an hash table and so forth. Reviewing some Javascript stuff of some web site for a customer? Hell, no, don't lose time with that shit. Comments

0 views
Hugo 3 days ago

AI and Ecology, Fantasy or Convenient Scapegoat?

It's hard to talk about AI these days. I've rarely, if ever, seen a subject so polarized in tech. You could tell me I have a short memory. The internet sparked plenty of criticism around the destruction of brick-and-mortar retail, print media, and the end of human interaction. Same for mobile, with added, legitimate reproaches about addiction and the ease of surveilling individuals. We could also mention crypto, a massive Ponzi scheme for some, a way to reclaim power from central banks for others. And yet, with AI, I feel like we've crossed a threshold. There would be only two possibilities: Pick a side, friend, and if you don't, others will do it for you. The "safest" bet is not to talk about it at all, but burying my head in the sand feels cowardly, if not impossible when you work in tech. Simply put, I need to stick my head out and try this exercise without resorting to clichés. And since we're in the middle of a heat wave, it seems obvious that the first subject to address is ecology. Is AI as catastrophic as people say? Is the impact of an AI query truly astronomically higher than a Google search? How does it compare with other digital uses? Let's take some time to look at all this. First, let's establish some basics about what we call ecological impact. This impact falls into several categories: To keep things simple, an AI consumes energy at two distinct stages: during training (when the model is created, like Gemini, Llama, Claude, etc.) and during inference (when users actually query the model). When looking at carbon footprints, models vary wildly, but the estimated range for training a single major model sits between 500 and 12,000 tonnes of CO2 equivalent. To put that into perspective: ::callout{type=primary} The massive gap between US and French household equivalents stems from the fact that France’s energy mix relies heavily on nuclear power, which is virtually carbon-free. :: Operational consumption is another moving target. It depends on the complexity of the prompt, the location of the data center (and its corresponding energy mix), the model being used, and so on. But it's estimated to vary between 0.03g , and 1g of CO2 per request. We'll see below how that compares with internet, gaming, streaming etc… To talk about water consumption, we must first address a common misconception: No, we don't destroy water . Earth’s water operates in a closed loop. When water is used in a cooling system, whether in a data center, nuclear power plant or anything else, it's not destroyed. When water evaporates, it eventually falls back as rain. However , evaporation causes water to displace. If water moves more than 800km, the region where it was drawn from has effectively lost it, temporarily but lost nonetheless. In ecology, we distinguish water withdrawal (borrowing water and returning it to the same place after use) and water consumption (drawing water and evaporating or releasing it elsewhere, making it unavailable locally). AI consumes water. On a planetary scale , it's not necessarily a problem. On a local scale , however, it can trigger severe water stress, creating direct competition between residents, agriculture, and data centers. To be fair, technology is advancing. The majority of new data center projects use closed-loop water systems so water isn't evaporated. Some countries (Ireland, Sweden, Finland) take advantage of their cold climate to reduce water needs by 90% and we see other systems emerging. But to look at the flip side, the vast majority of existing data centers use evaporation systems and in any case, these systems require electricity which creates tensions, for example in Sweden or Ireland. Now that we've said all that, what's the consumption for evaporation data centers? Training a recent model is estimated to consume approximately 40 to 80 million liters (a small lake). In a water-stressed region, that can make a difference. And if we look at usage, for a request, it's between 2 and 6.5ml of water per request. ::callout{type=warning} This section is the trickiest for me because it’s the one I’m least familiar with, and honestly, it probably deserves an entire article of its own. So, while we will only scratch the surface here, I promise to dive much deeper into this specific topic in a future post. :: We often focus on electricity and water, but the environmental footprint of mining is one of AI's biggest blind spots. To run AIs or train models, you need ultra-powerful equipment and colossal infrastructure that will require copper, aluminum, cobalt, lithium, nickel, rare earths and I imagine I'm forgetting some. Well, these resources are in limited quantities on earth but I'll discuss that in a future article, recycling in this sector is currently negligible but moreover, the extraction itself is extremely polluting. To make matters worse, we must add that current equipment becomes obsolete much faster. In the AI race, we replace equipment much faster. Certainly, new equipment is more efficient, particularly in terms of energy but this ultra-rapid rotation creates a volume of electronic waste we don't know how to manage. Despite everything, I don't yet know from which angle and with which figures to illustrate all this, especially since these subjects also pull along many other geopolitical subjects (tension over Taiwan, tension over rare earths etc…), so we'll set that aside for future publication. We already have plenty to do with the first two subjects. With these orders of magnitude in mind, is AI " stratospherically " different from the rest? How does it compare with a Google search for example? Or with streaming, video call, an online video game? By comparison, a query to a search engine (Google) is approximately 0.2g of CO2 . Depending on the complexity of the question and the model used, an AI prompt can cost slightly less than a Google search, or up to five times more . So, it is not "stratospherically" higher than a standard web search. Furthermore, if a topic requires you to do multiple Google searches and open several websites to find your answer, the gap quickly narrows, and can even reverse. But we must separate simple uses: "give me the strawberry pie recipe", from complex uses: "analyze this PDF document of several megabytes for me and create an application that displays results with charts". I propose we do an exercise and compare 1 hour of streaming, 1 hour of gaming, 1 hour of video call, and one hour of AI-assisted software development (a relatively power-consuming use). ::callout{type=primary} Why such strong variations when considering AI-assisted development? Because it encompasses vastly different habits. Consumption will be drastically different between an "amateur" coder copy-pasting a few lines from a browser, a "pro" user partially delegating tasks within their code editor, and an "intensive" power-user running automated tools where code generation is almost entirely outsourced. :: In other words: No matter how you look at the data, it is hard to find evidence of a "stratospheric" gap. And to go further, we could look at the impact of AI model creation compared to the ecological impact of creating a video game, or a movie. An AAA video game (big-budget), developed by a team of 150 people, costs between 500 and 3,000 tonnes of CO2 depending on development time, travel, and motion-capture filming. To this, we must add the annual maintenance for live-service games that push out continuous updates and DLCs (like World of Warcraft or Overwatch ). For a big budget film, we can estimate a carbon cost between 3,000 and 4,000t of CO2 , including transport, filming locations, generators, set construction. Granted, training a massive AI model can cost more than a single movie, but the difference isn't orders of magnitude apart. More importantly, we must remember that the world releases thousands of films and video games every year , whereas the creation of new foundational AI models remains relatively rare. Let's be careful here. It would be lazy whataboutism to simply say, "Sure, AI is bad, but look at how much worse everything else is." That is missing the point. The real goal here is to question our consumption habits as a whole. What is certain, however, is that the reality is far more nuanced than the mainstream narrative suggests. Today, the hyper-focus on AI serves as a very convenient distraction, allowing us to forget the environmental cost of our other digital habits. But you don't earn moral virtue points by campaigning against AI while actively indulging in online gaming, streaming blockbusters, or flying to international sports events. If you've followed the numbers well, the ecological impact of AI is relatively close to other impacts in digital (streaming and gaming for example). That doesn't mean it's good. In the world we live in, each additional tension on the planet is to be questioned . But it forces us to realize that all of our digital behaviors need to be reassessed, not just the fact that "I asked ChatGPT a question." I don't pretend to be able to rank these activities against one another. Comparing gaming, streaming, and professional workloads is highly complex. And even within professional uses, And I certainly won't decide, on my own , what constitutes a "good" or "bad" use of technology. But collectively, we might soon be forced to make those choices , not out of kindness, but by constraints (See next chapter). The core issue isn't about outright banning AI. This is precisely what organizations like Shift Project , France’s leading think tank on the energy transition, are trying to convey: we need to look at data volumes and digital use cases in their entirety. The argument isn't that we should abandon AI altogether, but rather that we cannot afford its current, unchecked trajectory Let's take an example: the FIFA World Cup generates between 9 and 15 million tonnes of CO2, which is roughly equivalent to the annual energy consumption of all US data centers combined.. Again, the idea isn't to say, they do worse. We'll get nowhere with that mindset. But I like this example because of the contrast it highlights. Playing football doesn't cost much. Gathering thousands of people across 3 countries and having them fly everywhere is absurd, as is air-conditioning football stadiums, or trying to organize winter games in a desert country. AI operates on the exact same spectrum. There is a massive gulf between a professional, high-utility application, like using AI in biochemistry, mathematics, meteorology, drug discovery, medical imaging, satellite analysis, or precision agriculture, and a purely recreational use aimed at generating thousands of Ghibli-style images just to dump them on social media. Yes, we can, and should, question the latter (and that’s an understatement). Ultimately, understanding these orders of magnitude is what empowers us to make informed choices instead of just parroting the absurdities we hear on TV. Once you know the real numbers, you can weigh your choices accurately. I said earlier that one hour of video call was between 30 and 60g of CO2. Ok, but that might replace a Paris Lyon trip. By car it's between 60 and 90kg of CO2 saved. By train it's about 1kg. Similarly, one hour of streaming costs about 100g of CO2. But if it prevented you from driving 20km to the local movie theater (which would cost around 4.4kg of CO2 in car emissions), streaming turns out to be "not so bad" after all. In the end, once we have the data, it is up to each of us to make those choices. A question I asked myself before writing this article was: If the carbon footprint of AI is actually pretty close to our other digital habits, and assuming it replaces some of them (if I’m using AI, I’m not doing something else), why on earth are we building so many new data centers? Ok, this question might seem naive but it's estimated that data center electricity consumption could double, or even triple by 2030 (See BCG study and this IRIS article). So why? Is it linked to AI? According to articles, partly yes, but only partly. The majority of electricity consumed by data centers (about 2/3) should be dedicated to historical digital uses and acceleration of cloud migrations. Yes AI plays a role, but it's mainly that digital is taking up more and more space. The share of digital in global CO2 emissions went from 2% in 2010 to about 4% today, with an annual increase of about 6% even though the global objective is to reduce our emissions by 5% per year to hope to ++stabilize++ the climate . Where AI genuinely worsens the problem compared to other tech is its rapid hardware obsolescence. However, the root cause is the massive scale-up of all our digital habits: the ubiquity of 4K/8K streaming, cloud gaming, high-fidelity music streaming, and the explosion of connected IoT (Internet of Things) devices. Of course, we should take these data center growth forecasts with a grain of salt. They remain predictions. They could easily be overestimated, just like the predicted "tidal wave" of data that was supposed to arrive with 5G but never quite materialized. Many of these projections are pushed by tech giants that have bet their entire financial futures on these exact growth scenarios. If you are Nvidia, Google, or Oracle, you have no choice but to reassure your shareholders by guaranteeing this growth will happen to justify the colossal investments already made. Honestly, if the AI financial bubble were to burst tomorrow, it might actually be good news for the planet, as it would instantly ease the pressure on our resources. That being said, we are looking at contracts that are already signed, budgets locked in, and massive public announcements, like the Stargate project or Europe's future investments . Every current scenario predicts a 2x to 3x increase in demand. Digital consumption is going up, and AI-related infrastructure is leading the charge. Will these digital habits replace physical ones (like my earlier example of a video call replacing a car trip)? Or are they purely additive ? Evidence suggests they are additive. While some AI applications will certainly accelerate decarbonization in specific industries, that impact remains relatively marginal for now. And, according to the Shift Project, it's mainly that the electrical consumption needed to run all these data centers will exceed our infrastructure capacity, and thus force using thermal sources (gas power plant) to compensate or create usage conflicts . So yes, it's alarming. Again, it's not about banning AI, the subject is much more global than that. How do we make our consumption and pressure on the planet decrease? At our individual scale, we have to audit our own habits. We need to question our obsession with upgrading devices, over-equipping our homes, and engaging in mindless, heavy recreational uses (like generating endless Ghibli images just for a laugh). At a collective level, we will eventually be forced, likely much sooner than we think, to make hard choices. We will have to decide whether to route precious electricity to a data center or to power and heat local homes . But let’s remember one crucial thing: the future isn’t set in stone. If we collectively choose to consume less, we won't need the electricity these companies are dying to sell us. If data centers are multiplying, it's only because there is a planned demand for them. To paraphrase a famous French comedian: "To think that if people just stopped buying, it wouldn't sell anymore!" The Doomers (declinists) who envision an ecological apocalypse, total destruction of employment and placing public opinions under the guardianship of Big Tech controlling AI. And the Bloomers (accelerationists), who advocate blind faith in progress, convinced that AI will liberate humanity, eradicate diseases and generate infinite growth, and for whom slowing research is the real crime. Electricity consumption (which translates into CO2 emissions) Water consumption for cooling data centers Resource extraction, required to build the data centers and user devices themselves There is only a 2x ratio between gaming and professional AI-assisted development. video call is what consumes the least Streaming is remarkably close to professional AI development usage

0 views
Binary Igor 3 days ago

The Order of Data: defaults, performance, determinism & paging

How does the database decide on the order, when it is not specified? What about performance? Can returned pages overlap? Meaning: might item from page 1 suddenly appear on page 2, even if the underlying data stays the same?

0 views
Unsung 3 days ago

My one (1) Medium secret

When I was at Medium, over a decade ago, I really enjoyed going deep on typography. = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/1.1600w.avif" type="image/avif"> People seemed to generally enjoy what we did. Writers really loved automatic em dashes and range dashes, discovered the beauty of hanging punctuation, and as funny as it might sound today, the smart quotes were a huge hit, too. I was proud of the tight drop caps, the underlines brought me some notoriety, and we even supported ligatures at a time when not only this wasn’t the default, but it also had some mildly scary performance consequences. = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/4.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/4.1600w.avif" type="image/avif"> But for every two things that worked well, there was also something that in retrospect proved to be me trying too hard, and had to be quickly undone. I was really excited about resurrecting pilcrows , but many users saw them as rendering or escaping errors. = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/6.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/6.1600w.avif" type="image/avif"> I briefly added vulgar fractions to all the places where Medium rounded numbers, but that made those numbers confusing and weird in practice. = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/7.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/7.1600w.avif" type="image/avif"> (And I already mentioned the strange, rare bug with system fonts , although I suppose there are always bugs.) = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/8.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/8.1600w.avif" type="image/avif"> It was an interesting calibration process. And somewhere in between successes and failures was one thing that I have never mentioned before, and one nobody ever brought up. I recently shared the story of 2015’s typographical redesign of Medium. As we were exploring the candidate typefaces, we fell in love with one in particular: Charter , a font designed by the industry legend Matthew Carter – and no, this is not a bug, Google Search switches to using Carter’s own Verdana to honor him. Charter had this perfect balance of “casual” and “refined” we wanted for Medium at the time. Unsurprisingly, it also came with a bunch of typographical niceties – among them lowercase (old-style) digits, which I really wanted: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/9.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/9.1600w.avif" type="image/avif"> But there was a problem. Those lowercase numerals came with a “medieval 1,” a particular style of a lowercase digit 1 that resembled an uppercase I. People hated it and were confused by it, thinking indeed that a bug caused a letter I to make its way to the numbers. No amount of pleading would get us to push that digit through. The backup plan was going with uppercase numerals, but I hated the idea; those digits felt so ugly and pedestrian to me – they were not just uppercase, but also monospace! It was a frustrating situation, being so close and yet separated from a warm Charter embrace by one glyph that it didn’t happen to have. And so… I drew one. = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/10.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/10.1600w.avif" type="image/avif"> I, someone who has never ever designed a typeface, decided to vandalize Matthew “ The Most Widely Read Man In The World ” Carter’s typeface and plop in a new digit 1 of my own creation. = 3x)" srcset="https://unsung.aresluna.org/_media/my-one-1-medium-secret/11-framed.1600w.avif" type="image/avif"> The internal complaints stopped. Weeks later, we launched the new fonts, Charter front and center, my fresh non-medieval 1 attached. I don’t remember the exact details, but we found a way to do this that was compatible with the font’s licensing – and yet I never talked about it because… well, I think you can understand why. I believe my rogue 1 lasted until a subsequent redesign in 2022, long after I left the company. A decade in, I still don’t know how to feel about it. Did I save Charter as a candidate for Medium by mutilating it a bit, am I writing this post just to launder my own ego, or is this the equivalent of a perp coming back to the scene of the crime? Was I ambitious (laudatory) or ambitious (derogatory)? Maybe you can tell me. But I hope either way it makes for a fun story. #above and beyond #craft #hacks #marcin wichary #typography

0 views
Kev Quirk 4 days ago

📝 2026-07-12 10:08: It's a beautiful morning here in North Wales. My wife has taken our youngest to...

It's a beautiful morning here in North Wales. My wife has taken our youngest to his cricket match, and our oldest is upstairs playing with his Lego out of the heat. Me? I'm sitting in the sunroom, listening to the goats and chickens, with a coffee and book. Perfect Sunday morning. Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .

0 views
seated.ro 4 days ago

You fail to learn if you don't learn to fail

If all your time is spent watching output tokens, where do your input tokens come from? Letting an agent rip on full auto is basically doom scrolling. Even worse if you're doom scrolling while the agent runs. We humans love frying our dopamine receptors. This feels great until you realize what you were offloading: the struggle. The part where you fail. Failure is the entire point. You don't make progress in the gym unless you take a set at least close to failure. The muscle only adapts when it's forced to. It is no different for the brain. It is very hard to admit to yourself that your skills have atrophied. It is even harder to admit this to other people. I will admit that over the past several months my brain has gotten smoother (and I wasn't even on Twitter much!). Recently, I had written an abstraction for my diff viewer ( diffy ), an element system with a macro that lets agents write html-like code in rust for native ui (they reason better with this). But it wasn't adopted everywhere in the repo yet, so when I asked for a new feature, the model decided to hand paint it straight to the viewport instead. Every behavior the element system gives you for free was just... missing. Text wasn't selectable. Hover highlights wouldn't go away. And since I wasn't looking closely, it iterated on the slop and produced more slop, more bugs. I just kept saying continue. I lost a whole day untangling it, and the funny part is that once I actually looked at what it had built, every bug was the same bug. When you hit a roadblock and your immediate reaction is to reach for something else (previously, this used to be other people, but now it is a language model) you are essentially skipping the part where you actually learn to solve the problem. It is funny how one of the best "learning tools" has turned out to be the number one cause (anecdotal. sue me) of the lack of learning! It's been a few months since I started writing this, and things have gotten more dire. Several major software services barely work now, grown engineers I once respected are writing somber posts about missing a language model that was banned for a while. Mourning. For model weights. It's all so dystopian. As the agents get better, one is basically expected to produce code at an alarming rate. The timeline to get something done is compressed but the time it takes to come up with solutions to hard problems has not. There are usually a few good abstractions one can come up with that balance the upsides and tradeoffs for most software problems. However it is currently trivial to turn your brain off and let the slop flow. The code will be complex. It might look like it all works, but something always breaks. And the solution to that? More slop. Software quality is collapsing as a result, and the societal expectation that engineers understand what they ship is disappearing. You never understood the code in the first place. So when you need to change it, you're asking the same stateless clanker to modify code it has no memory of writing. All output tokens and zero thinking tokens. A lower barrier of entry to write software doesn't imply the standards for good software must be lowered. The growing trend is to do things because you now can (supposedly), but we used to try and do things because we could not out of sheer stubbornness. Carmack and gang shipped QuakeWorld with client-side prediction over dial-up when the conventional wisdom was that twitch shooters over the internet were unplayable. This only happened because Quake's original netcode was laggy and everyone hated it. (They fixed it in a month.) George Dantzig arrived late to class, mistook two "unsolvable" statistics problems for homework, and solved them. Nobody told him they were impossible, so he just did the work. Andrew Wiles spent seven years alone in his attic working on Fermat's Last Theorem, a problem mathematicians had given up on for 350 years. He announced the proof, a reviewer found a hole in it, and he spent another year fixing that too. Notice that all three of them became who they are because of the struggle, not despite it. The people benefiting most from generative tools today, say Terence Tao or Mitchell Hashimoto, already put in the time, so when they offload work they're just skipping the typing. When people like you and me (if this is not you, then I apologize) offload, we skip the grind itself. With language models, easy tasks got easier, hard tasks stayed hard. The hard part was never the task itself. I don't know, I am figuring this out as I go. The amount of time I have spent actually programming has been dropping month over month this year. I used to have a coding stats section on my website that would track hours I spent writing code split by language, recently I had updated it to this: and it made me quite sad. I do think that sometimes all you need is to realize that the thing you are doing is actually detrimental to your growth. Consistency matters more than one would assume. If you consistently take some time away from these tools and actually use your brain, that alone is already significantly better than offloading your thoughts. Solve the problems yourself. Or at least try, fail, and spend time thinking. There is seemingly no "learning" phase anymore. You are expected to just know things. Learning is fun, don't let anyone take this away from you. I've written about this before . It is probably going to be slow, learning takes time and effort. You will feel stupid (I feel stupid). This is a good feeling, because there exists a world where you are no longer stupid and the path towards it is learning. Books still exist! Libraries are still open, notebooks waiting to be written in. Read more. Write more. If you really do care about improving yourself, be honest and use these models for what they are, highly efficient filters of zettabytes of data (the internet is estimated to be 175-240 zettabytes ( 10^{21} bytes)). It was extremely difficult to identify what one needed to read to learn niche topics even like 2 years ago. I remember asking a good friend of mine to recommend material to dive deep into learning about SIMD, and honestly there wasn't much stuff to read except the Intel Intrinsics Guide. And if you've ever taken a look at that, it is quite cancerous for a first-time reader. Language models are super useful here because you can point them at material and you can ask questions that pertain to the thing you care about and it will simply just tell you the correct things. One good thing in this age of slop is to consume knowledge at an unbelievable pace. I don't necessarily mean using only model output for learning (I don't trust them to learn any topic more than a shallow amount), but rather using them to help sift through the plethora of information available out there and identifying the right things to read. Human slop exists too and using a language model to supplement your learning might help keep you sane (ironically). I like using these models to write code that I tell it to write (outside of work I enjoy doing it myself entirely), and I am largely disinterested in asking it what I should write. There are exceptions of course, because not everyone is working on scaling software services which has largely been solved (but slowly being forgotten), but that would be for you to decide. The best model you have access to (and it has solved continual learning) is, and always has been, the one inside your skull. It's time to scale up its input tokens.

0 views
DHH 4 days ago

But Y

It's no mystery to me why the Tesla Model Y is the world's best-selling car. As a total package, I could make a fair argument  that it's simply because it is the world's best car.  I'm no stranger to Teslas at this point. We've owned a Model S Plaid, the Model X we traded in on the Y, and we still have the Cyberbeast too. But as impressive as all those cars are, the Y towers above them in several key respects, but first and foremost, value. The premium all-wheel-drive white-on-white seven-seater we just got was right around $55,000. That's not exactly cheap, but it's less than half of what we spent on any of the other Teslas. It's a quarter of what we spent on the Porsche Taycan Turbo S. It's a sixth of what a new Aston Martin DBX would set you back. And, if I could just have one car, I'd pick the Y over all of them. The first thing you notice coming from earlier Tesla models is just how well-built the new Model Y is. The gigapress process that produces these new cars results in a package that feels reassuringly solid: no squeaks, no rattles, no flex. This couldn't be said about any of the earlier S and X models we had. But compared to other makes, it's not exactly revolutionary that a brand-new car feels well put together. Many other makes have managed to perfect that process over the decades. Tesla has now merely leapfrogged itself to the front of the class. But what very much is revolutionary is just how effortless owning the Y feels. It starts with entry and exit. Once you've paired your phone, you never think about keys or starting or stopping the car again. It just happens. There's no on/off button, no starter, no unlock. Again, other makes have made attempts at this, but none that I've tried is even close to the effortlessness that Tesla's superior software stack is able to deliver. Speaking of software: It just works. Every time. Going anywhere. You don't miss Apple CarPlay or Android Auto for a second. The navigation, the Spotify integration, the setup. Everything feels like it was written by a leading American software company. Not subcontractors out of India or firmware developers forced to deal with user interfaces. But where everything comes together is FSD. The self-driving technology that Tesla pushed against all odds for over a decade is finally here in an utterly magical incarnation. The car not just drives itself anywhere, it drives better than almost any human I've ever been driven by has been able to do. Its ability to anticipate traffic patterns, hit the perfect deceleration curve towards a light, slow down for even minor speed bumps, and gracefully curve around pedestrians or cyclists is nearly unbelievable.  As in, you'd be forgiven the suspicion that there must be a human driver hidden somewhere controlling the car over the internet. But it's just AI, and it's gotten fiendishly better over just the past year or so. All in service of that effortless experience. In fact, I'd go so far as to call it a luxurious experience. Like you're being escorted by the Queen's own driver to your desired destination. The Queen wouldn't bother with keys or rattles or driving. She'd just get in, be driven, and arrive fresh for a waive. This is the best approximation you can buy for mortal money today. But then, unlike the old X, it's actually also surprisingly delightful to grab the wheel yourself, hustle it down a hill, lean it into some fun corners, and surge out on that wave of endless torque that electric motors always deliver so well.  No, it's not a Porsche 911, but I'd say it's 90% as fun as a Taycan, at a fraction of the price, in a package that's endlessly more practical, and — did I mention this already? — can drive itself once you're done with the spirited part of the journey. The Tesla Model Y is a triumph of capitalism. Making the best self-driving technology available to the masses at a price that's accessible to the middle class in a car that even billionaires would appreciate.  Andy Warhol captured this egalitarian celebration well with this sentiment: “A Coke is a Coke and no amount of money can get you a better Coke than the one the bum on the corner is drinking. All the Cokes are the same and all the Cokes are good.” The Tesla Model Y is an incredible car for nearly everyone.

0 views
Unsung 5 days ago

“Not being good at something doesn’t mean you can’t love it.”

Perhaps ironically given the subject matter, I found this 34-minute video by Razbuten a bit intense, but I would still recommend it to people who work on onboarding, settings, etc.: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/not-being-good-at-something-doesnt-mean-you-cant-love-it/yt1-play.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/not-being-good-at-something-doesnt-mean-you-cant-love-it/yt1-play.1600w.avif" type="image/avif"> In the video, the author tries to answer the question: how to make any given game a challenge, given there is no universal standard of difficulty and every player arrives at a game not just with different skillset, but also likely different goals. There are many techniques a game can use to adapt to the player – a simple upfront difficulty selector, complex difficulty settings, a training level, adaptive difficulty, accessibility/​assist modes – but there are no easy answers. Each method comes with pros and cons, and perhaps the very notion that a game should adapt to the user is flawed; some players might find it more rewarding to have to step up to the game instead. In the video, Razbuten covers a lot of examples really well. I’m not going to say any of this maps 1:1 to productivity software as goals of games are very different than goals of apps… but even though I have never played any of the games mentioned, the examples made me think. After all, some of the psychology of mastery will be the same between these two realms. (I bet there were at least some of you who saw the previous post about LaTeX and thought “this looks hard and fascinating – I’m going in,” and others took a note to never approach it.) #flow #games #onboarding #settings #youtube

1 views

Establishing an Identity

If you’ve followed me on RSS for any amount of time, first off, thank you so much! Second, you may not have noticed how often this site changes. RSS protects you from the near-monthly changes that my mad scientist side makes to this site. This year alone, ThatAlexGuy.dev has been powered by 11ty, Hugo, plain HTML, Bear, Micro.blog , and Pure Blog. My files have sat on OpenBSD Amsterdam, DigitalOcean, and a Laravel Forge VPS. I’ve written new articles and lost old articles in migrations. My site has switched appearance more frequently than a Bian Lian (变脸) performer! I’ve come to realize I’ve been seeking both an identity and a voice. I want an outlet that reflects my interests, my background, and my day-to-day, but that’s more than what I could accomplish on something like Mastodon. All that brings us here, iteration 4 (or 8, or 15, or 16, I can’t remember). There are a few key differences and intentional choices that reflect where I want ThatAlexGuy to go. Building a new experience that will stick and satisfy the goals in my head won’t be easy, but here are the guiding pillars that are to shape what’s coming next. I have a desire to create in-depth, well-researched, and potentially interactive content. Many of my current posts come with a “1-minute read” tag. I want to change that. I’ll be digging into topics with greater detail, cross-referencing multiple sources, and (hopefully) interviewing others. As a result, I’ll be posting less frequently, but my new goal is quality over quantity. Regulars on my site will be aware of my “Photo Journal” series in which I posted a set of photos around a theme (macro, nature, Gameboy Camera ). I want to continue building my photography skills through the incorporation of high-quality photos in my articles. While text sets the tone, visuals set the atmosphere in an article. Here’s the big tomato, as they say (nobody says that): defining what this site represents. That means setting the tone and defining how topics string together to form a consistent narrative. I’ll be figuring this out for a while, but I want to leverage my interests such as indie technology, vintage computing, time away from the screen, photography, and Chinese culture. So what’s changed so far? Quite a bit! First, ThatAlexGuy.dev is now run by Ghost.org . For myself, this means less time in the technical weeds and more focus on writing. For readers, it opens the doors to a wider audience. Email newsletters are a more accessible way to stay up-to-date on new articles. Don’t worry though, RSS isn’t going anywhere! In fact, I managed to fix the broken RSS feed URLs from previous migrations (hopefully)! I’ve started to define the personality of the new site. I pulled background and accent colors from one of my favorite atmospheres in a game (Sprout Tower in Pokémon Gold). Using my iPad, I’ll be creating article images that give a calligraphy + hand-painted vibe. I’ve also brought in my Chinese name for the logo(小艾 - Little Alex). I’m working on my first longer-form article. It probably won’t be great, but first attempts never are. From there, I hope to refine my writing, researching, and supporting photography.

0 views

Dot product: Component vs. Geometric definition

The goal of this post is to answer a simple question: why are the following two definitions of the vector dot product in Euclidean space [1] equivalent for vectors \vec{a} and \vec{b} : Here’s a graphical depiction of our vectors (focusing on for clarity, though this applies to any-dimensional vectors). It shows both the components of the vectors and the angle between them. The length of the arrow for \vec{a} is |\vec{a}| . We’ll show two proofs of the equivalence here, the geometric proof and the projection proof . The Appendix describes some properties of dot products that facilitate these proofs. We’ll be using this diagram of our vectors \vec{a} and \vec{b} , as well as the vector \vec{c}=\vec{a}-\vec{b} : Using the law of cosines [2] on the triangle formed by the three vectors: Since for any vector \vec{a} , we have \vec{a}\cdot\vec{a}=|\vec{a}|^2 (see Appendix), let’s rewrite this equation as: But \vec{c}=\vec{a}-\vec{b} and the dot product obeys the distributive property (see Appendix). Therefore: For this proof, we’ll assume the geometric definition is correct and will see how it leads to the component definition. We’ll begin by denoting vectors \vec{e}_1,\vec{e}_2\dots\vec{e}_n as the standard orthonormal basis for . For example, in 2D space, these basis vectors are \vec{e}_1=[1\ 0] and \vec{e}_2=[0\ 1] , shown in this diagram: If we take an arbitrary \vec{a}\in\mathbb{R}^n and calculate its dot product with a basis vector, we can use the geometric definition: where a_i is the component of \vec{a} in the direction of \vec{e}_i . The diagram makes it easy to see why this is true from basic trigonometry, but in the more general case this is just a vector projection . Now let’s represent vectors \vec{a} and \vec{b} as linear combinations of the basis vectors: And calculate the dot product \vec{a}\cdot\vec{b} , beginning by rewriting \vec{b} with its linear combination of basis vectors representation: Using the fact that the dot product distributes over linear combinations: But earlier we’ve shown that \vec{a}\cdot\vec{e}_i=a_i . Therefore: Which is the component definition \blacksquare . A generalization of dot products in is the inner product , which is an operation meeting some specific requirements, defined on a vector space. The inner product is denoted as \langle x,y\rangle:\mathbb{R}^n\times\mathbb{R}^n\to\mathbb{R} , and must satisfy the following requirements for all vectors x,y,z\in\mathbb{R}^n and scalars a,b\in\mathbb{R} : For , we define the inner product operation in its component formulation as: Let’s prove the requirements listed above for this operation; this is fairly straightforward, given the well-known properties of scalar multiplication and addition on : Linearity in the first argument: Positive-definiteness: Consider the components of vector x . Clearly, \forall i\quad x_i\cdot x_i=x_i^2\ge 0 . Since the vector x is not the zero vector, at least one of its components is nonzero, and for that component x_i\cdot x_i>0 . Therefore: Now that we’ve proved all the inner product requirements on our operation \langle x,y\rangle , we can say that is an inner product space with this operation. By meeting these requirements, it can be readily shown that our inner product operation has additional useful properties: The third property is particularly helpful, because it means the inner product is bilinear , and thus is distributive over addition. Note that these are shown for the component definition of dot product. It’s not too hard to prove distributivity for the geometric definition using the notion of projections and how they add up. The norm of a vector x in an inner product space is defined as |x|=\sqrt{\langle x,x\rangle} . Therefore, the square of the norm is |x|^2=\langle x,x\rangle . The norm is used to express the notion of magnitude , or length of a vector. If you think of a vector x\in\mathbb{R}^n in Cartesian coordinates, the definition of the norm is a generalization of the Pythagorean theorem. Component definition: \vec{a}\cdot\vec{b}=\sum_{i=1}^{n}a_i b_i Geometric definition: \vec{a}\cdot\vec{b}=|\vec{a}||\vec{b}|cos(\theta) , where |\vec{a}| is the magnitude of \vec{a} and is the angle between the vectors’ directions Symmetry: \langle x,y\rangle=\langle y,x\rangle Linearity in the first argument: \langle ax+by,z\rangle=a\langle x,z\rangle+b\langle y,z\rangle Positive-definiteness: if x\ne 0 then \langle x,x\rangle>0 \langle x,0\rangle=\langle 0,x\rangle=0 \langle x,x\rangle=0 if and only if x=0 \langle x,ay+bz\rangle=a\langle x,y\rangle+b\langle x,z\rangle \langle x+y,x+y\rangle=\langle x,x\rangle+2\langle x,y\rangle+\langle y,y\rangle

0 views
Sean Goedecke 5 days ago

In defense of not understanding your codebase

As a software engineer, how well do you have to understand your own codebase? My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness ) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”. These are two largely different ways of programming with different methods, practices and cultures 1 . However, the first group is over-represented in online discussion about software engineering 2 . I want to defend the second group against the first. In many software engineering environments, there’s nothing wrong with being in a state of partial understanding. In fact, in large systems a partial understanding is the best you can do. The best articulation of the “you have to understand your codebase” side is Peter Naur’s famous paper Programming as Theory Building . I like this paper, but I think it goes too far in that direction. Naur’s core point is that when programmers work on a program, the code is really just a by-product, and the main product they’re working on is their “theory of the program”. That’s made up of their intuitive sense of what’s happening and why, which can only be partially captured by code or documentation. If they lost the code, they could rewrite the program easily. If they lost their understanding (say, if the team experienced 100% turnover), they would struggle to make sense of the code. So far, so good, but Naur goes further than this. He says that the theory should not be reconstructed from the code. According to Naur, you’re better off scrapping the program entirely and having a new team rebuild it from scratch , building up a new theory in the process 3 : reestablishing the theory of a program merely from the documentation, is strictly impossible … [therefore] the existing program text should be discarded and the new-formed programmer team should be given the opportunity to solve the given problem afresh Anyone who’s been an effective software engineer at a large company knows that Naur is dead wrong about this. There are at least two reasons. First, you simply can’t rebuild large software systems from scratch . Sufficiently large systems (if they have users) contain thousands of weird cases and quirks that cannot be reimplemented. Even a team that’s intimately familiar with the system couldn’t do it: there’s just too much stuff to juggle. Successful rewrites always start by carving out the existing codebase into small isolated chunks, then rewriting one chunk at a time. In other words, rewriting a software system involves making a bunch of changes to the old system. If you can’t change the old system, you certainly can’t replace it with a new one. Second, abandoned systems are revived all the time . In a tech company with hundreds of millions of lines of code and thousands of engineers, it’s not uncommon for a codebase to have nobody left who’s familiar with it 4 . All it takes is a few people to quit at the wrong time, or for a codebase to be unmaintained for a year. Not only have I seen other teams do this, I have personally taken ownership of abandoned codebases, figured them out, and gotten to a point where I could effectively work with them. It takes time, but building a new theory of the codebase is possible. You start by understanding one flow end-to-end, then slowly branch out from there, making careful changes as you go. In sufficiently large codebases, everyone operates with an incorrect theory of the program . The defining feature of modern software systems is that they’re just way too big for anyone (or even a whole team) to keep in their head: nobody understands it all . To be effective, you have to figure out a way to work with a merely partially-correct theory. This is why I keep going on about taking a position and confidence . If you’re not sure about something, you can’t just sit back and wait for someone with a perfect understanding to come and give you the answer. If you’re a competent engineer, that person is you . You have to grit your teeth, make your most educated guess, and then deal with the consequences. To be generous to Naur, it’s possible that in 1985 the average size of a program was several orders of magnitude smaller than today, and that when Naur writes about “large programs” he’s not talking about tens of millions of lines of code. Naur’s first example of a large program is a 200,000 line industrial monitoring program, and his second example is a compiler. In 1987, the first version of the compiler GCC was about a hundred thousand lines of code; in 2015 GCC was over fourteen million lines. I can believe that rewriting one or two hundred thousand lines of code is relatively straightforward, particularly if you get to reuse existing tests. Not so for one or two million. LLMs are often cited as a tool that’s bad because it impedes the ordinary process of theory-building. I think this is overly simplistic. Like many software tools, LLMs are a double-edged sword: they make it harder to construct a detailed mental theory of the software, but they allow you to build a partial theory quickly and they can help you leverage that partial theory more effectively. This is a complex tradeoff that I’m still thinking about. Setting LLMs aside, I’m confident that it’s silly to say that anything that interferes with your theory of the software must be bad. Here is a partial list of other things that make it harder to maintain a theory: Like most things in software, “maintaining a theory of the codebase” is one value among many. Sometimes it’s the most important value and you sacrifice other values for it; other times you trade it off for speed, or legal compliance, or for political reasons 5 . Almost all engineers — particularly “pure” engineers — prefer to maintain an accurate mental model of their software. It’s more fun, less stressful, and feels more like “real engineering”. That’s why many engineers take up open-source projects in their spare time in order to work on small codebases by themselves: in order to do engineering work where they can maintain an accurate Naur theory of the codebase. I don’t think there’s anything wrong with that. However, at work you are paid to do a job . In other words, they pay you money to adopt their set of engineering values. It’s hopefully well-understood that however much you might personally care about performance, sometimes you have to write slow code at your job (for instance, to get a project done on time, or to accommodate some awkward requirement). Maintaining a theory of the codebase is the same kind of thing. I wrote about this at length in Pure and impure software engineering . I think many of the repeated arguments we have in the software industry are caused by the pure total-understanding culture coming up against the impure partial-understanding culture. Open-source engineers are more excited to blog about their work, the raw engineering content is typically more impressive (because coordination problems dominate big proprietary systems), open-source projects can be legally written about while proprietary systems can’t, and even if you could do it legally, writing about large codebases is impossible because it requires too much specific context . I re-read the relevant chapters of Ryle’s The Concept of Mind (which Naur cites throughout) and I think Ryle is more generous about theory-building. For Ryle, theory-building or know-how automatically happens as you do things. It’s fully consistent with Ryle to think you can pick up an existing codebase just from the code, purely by puzzling it out. Naur says: “Lest this consequence may seem unreasonable, it may be noted that the need for revival of an entirely dead program probably will rarely arise, since it is hardly conceivable that the revival would be assigned to new programmers without at least some knowledge of the theory had by the original team.”. If only! Some engineers might say that maintaining a theory is the core value, because without it you can’t fulfill any of the others. I disagree. You could say the same thing about readability, or maintainability, or correctness, or a bunch of other engineering values. We trade off “core” values like this all the time. Other people being allowed to write code in your codebase Having to implement legally-required features like accessibility and data protection Allowing your colleagues to quit their jobs or move between teams Having to upgrade software versions for security patches Bringing in libraries or other dependencies I wrote about this at length in Pure and impure software engineering . I think many of the repeated arguments we have in the software industry are caused by the pure total-understanding culture coming up against the impure partial-understanding culture. ↩ Open-source engineers are more excited to blog about their work, the raw engineering content is typically more impressive (because coordination problems dominate big proprietary systems), open-source projects can be legally written about while proprietary systems can’t, and even if you could do it legally, writing about large codebases is impossible because it requires too much specific context . ↩ I re-read the relevant chapters of Ryle’s The Concept of Mind (which Naur cites throughout) and I think Ryle is more generous about theory-building. For Ryle, theory-building or know-how automatically happens as you do things. It’s fully consistent with Ryle to think you can pick up an existing codebase just from the code, purely by puzzling it out. ↩ Naur says: “Lest this consequence may seem unreasonable, it may be noted that the need for revival of an entirely dead program probably will rarely arise, since it is hardly conceivable that the revival would be assigned to new programmers without at least some knowledge of the theory had by the original team.”. If only! ↩ Some engineers might say that maintaining a theory is the core value, because without it you can’t fulfill any of the others. I disagree. You could say the same thing about readability, or maintainability, or correctness, or a bunch of other engineering values. We trade off “core” values like this all the time. ↩

0 views