default-kramer

Sorry for off-topic, but: Is the SSL certificate actually bad, or is Spectrum screwing with me somehow? And if so, how? I'm using Cloudflare DNS, so how can Spectrum even do anything about it? Unless they are MITM-ing my DNS queries, which I suppose is possible but it's a level of chicanery I've not seen yet.

Yes, when considering software design it's great when you can "smuggle in" a new dependency by adding a new property or method on some already-established payload. I would describe this as "The change requires someone way up the stack to change, but all the intermediate layers require no source changes" which is notably absent from the author's list of "three basic cases that can emerge." I assume the author is well-aware of this technique but considers it equivalent (for the purpose of function coloring) to "The change may require a change to all functions in the stack" since technically the signature of all those intermediate layers did change.

I chose a connection string as an example of something that obviously cannot be originated in the middle of the call stack. The difference between passing a raw connection string or passing a connection factory is important for good software design, but I considered them equivalent in the context of this discussion of coloring.

> What would it even look like for the top-most function to have to know “everything” that all the child functions end up ever needing? For every function parameter change in the entire program to somehow force a change all the way up the entire call stack? Clearly this does not happen. It so thoroughly does not happen that you may be having difficulty even imagining what it is I am talking about.

Really? In my experience, it certainly does happen and I'm generally happy (but not thrilled) when it does. It means the type system is doing its job, forcing me to provide all the dependencies that a function needs. If 38 layers deep something now needs a connection string that it didn't have before, that had better bubble up to the top-most function. Unless of course the top-most function has already provided it to an intermediate layer which can break the chain, but that is very different than the context.Background() example.

I value writing style and pacing way more than any volta. Pride and Prejudice is hardly my genre, yet I remembered it grabbing me immediately. So just now I checked to see if I remembered it correctly, and within the first minute I laughed and I'm hooked again.

Life's too short for novels that might get good halfway through, especially when there's plenty Austen I haven't read yet.

> the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done

Perfectly said. It was true before LLMs too.

As I've been reviewing more and more LLM code, I've noticed that while good developers can use LLMs to produce good code maybe 1x-5x faster (depending on circumstances), bad developers can use LLMs to produce bad code 1000x faster. And if you are collecting metrics that only capture that 1000x number, I bet you feel great about what you're doing.

> I probably spent over 20 hours debugging, scanning the emu-dev Discord, creating tests, and even throwing the issue at earlier AI models. Nothing worked. But then after a few weeks away from the emulator I tried Claude Opus, and it found the issue in just a few minutes.

Even if you want to write all the code yourself (which is a fine decision), the only reason in 2026 to bang your head against a problem like this for 20 hours is if you really enjoy doing so.

(I'm surprised that "earlier AI models" didn't work for the author. For me, free-tier Gemini gets stuff like this correct all the time.)

I think it's another case of the whole industry being driven by the needs of the very small number of systems that need to handle >10k concurrent requests.

What's strange is that many people who believe in a Mature Creation (as I've heard it; "Last Thursdayism" is new to me) will readily accept it as the explanation for ancient starlight but then deny evolution and claim that the fossil record is actually evidence of the biblical flood. Which is an unnecessarily weak position to take when you have already accepted a perfectly unfalsifiable cop-out! The truth is that most of them don't want to think too hard about it.

I'm not really concerned about the availability of SW dev jobs, but I am concerned about the quality of them. For many companies the velocity (and quality, much to my chagrin) of the code you can produce doesn't really matter. What matters more is whether or not you're building the right thing, and too often you're not. These companies also tend to keep more headcount than seems justified, I think because they are gambling that a few employees are going to do something awesome but they don't know which ones. As AI gets better what will these companies do? I don't think they will fire a bunch of SW devs. I think instead they will embrace the slop and just take more shots, and crazier shots. It doesn't just give us something to do, it also gives a bunch of PHBs something to do.

You're right, but for EDM this was pretty much already the case. The scene survives in large part thanks to DJs who wade through countless mediocre tracks looking for the few hidden gems to deploy at the right moment. I think AI means that DJs will become much more important in all genres.

> But for the time being there remain a few things that humans can do very easily which computers find difficult. Along with counting traffic lights and crosswalks, one of those things is finding the exact BPM of a song. Not an estimate like most software does, but the exact value with extreme precision across the entire song.

I thought BPM detection has been extremely precise for some time now (for electronic music anyway). Does this mean when software like Mixxx reports (for example) 125 BPM the raw output of the algorithm might have been 124.99, but some higher logic replaces it with an even 125?

I formerly worked for a travel company. It was the best codebase I've ever inherited, but even so there were select N+1's everywhere and page loads of 2+ seconds were common. I gradually migrated most of the customer-facing pages to use hand-written SQL and Dapper; getting most page loads below 0.5 seconds.

The resulting codebase was about 50kloc of C# and 10kloc of SQL, plus some cshtml and javascript of course. Sounds small, but it did a lot -- it contained a small CMS, a small CRM, a booking management system that paid commissions to travel agents and payments to tour operators in their local currencies, plus all sorts of other business logic that accumulates in 15+ years of operation. But because it was a monolith, it was simple and a pleasure to maintain.

That said, SQL is an objectively terrible language. It just so happens that it's typically the least of all the available evils.