dcuthbertson

It's the mischief caused by shadow onions lurking in dark corners of the market bins that make me cry.

but every setup plays against every other one and earns an "honest" score. /scream

I'm not convinced, yet, that eliminating LLM-generated comments is the right path for me. I do review everything written by an LLM and some comments are actually pretty good, but sometimes I'm just too tired to try to figure out how to reword an oddly worded one.

I just added Sanglard's rules to my ~/.claude/CLAUDE.md file, did another code review, and found some LLM-generated comments were really hard to understand. I think they're due to invented metaphors and flowery language instead of using standard terms, so I've added this:

- Comments must be literal. Don't invent figurative language for what a plain technical term already says — write "rows still reference it," not "rows still wear it."

Improving LLM code generation is an iterative process. I'm glad people share their efforts to improve it.

I worked for a company that measures developer's output in number of commits, PRs created and approved, and Jira tickets per sprint. Management doesn't even insist on that the tickets have any kind of an effort estimate.

It can be pretty depressing, until you learn how to game the system - create tickets for yourself that are tiny amounts of work. I hear that it's getting harder to do that, because management is looking more carefully at tickets generated and it looks like they'll start having developers assign points to their tickets before the tickets are added to the sprint

> If a() calls b(), I wouldn't think the stack frame while running b is the ancestor of a.

I think of b as the child/descendant of a because a creates the running instance of b, and that makes a the parent/ancestor of b.

> 2000 - 2999: 21st century

You have the right idea, but you made the 21st century a millennium

I too have written C programs for decades. I encountered reference counting when I learned how to write Windows kernel drivers. It was very liberating to see that there were so fewer opportunities for memory leaks when reference counts were applied liberally.

TIL that statements of obvious exaggeration are called causal, hyperbolic statements. Who knew?

All kidding aside, I've never heard them called causal hyperbolic before. It's a good term.

I'm curious as to how low a temperature your heat pump will operate. I live in New England and replaced a whole-house air conditioner with a heat pump, but the heat pump works only to 35F. Much colder than that, and an auxiliary electric heater kicked in. The first Winter cost me about $800 over my gas-fired forced hot water heating system. I had the contractor disable the electric heat in the Spring and rewire the thermostats to start the (high efficiency) furnace when the outdoor temp got too low.

Imagine your own, household matter/antimatter reaction chamber. I can hardly wait for antimatter to be transported through pipes underground along side water mains, natural gas pipes, and sewer connections.

But doesn't No. 2 directly conflict with Pike's 5th rule? It seems to me these are all aphorisms that have to be taken with a grain of salt.

> 2. Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process.

There are few things so valuable as a good user who is willing to work with you. Many years ago I worked at a company that was going to shutdown a very buggy product. There was one user who relied on it heavily and convinced the CEO to make one more release, and I was tasked with working with that customer to make it happen. Over the next month, we fixed the bugs (I coded, he tested). We wound up making a stable and more user-friendly product. It was a real pleasure to work with that guy. The company still mothballs the thing, but I know we had at least one happy customer in the end.