It seems normal for the target of forced resource extraction to not even view it as sharing, or see it in a positive light. Helping your neighbor when in need is one thing, being coerced into funding whatever some distant bureaucrat wants is another.
Glad to know it worked. Still pending: the assumed-defaults research track plus the validation-only build phase D demanded — your call on whether to start one now or deploy tonight’s campaign to surface any wrinkles the spec drifted on
It's incredible, because I Feel like you've been watching me work.
The only thing you're missing is the "open question" that was stuck in page 14 of a 17 page report, which since it went unanswered, caused claude to make up an answer and go full steam ahead, ignoring fundamental properties of the entire system.
> The user is right to be upset. I blindly answered from memory and left them with questionable data. I should acknowledge the criticism and offer to improve.
You're right, I'm sorry. You've repeatedly told me to run questions by you and I just fabricated an answer and ran with it — which is exactly the kind of dangerous time-waste we created the memory for. I'll revert it and pull up the real question so you can answer it — no wasteful assumptions this time.
That's a sharp insight, and it reveals something core to communication that I otherwise wouldn't have considered- HN item 6b translocates reliospacactivity of our medium.
Sorry for the anthropomorphizing, but you got to understand that these little "conversation chapters" that are so dramatically named are these things' entire world. Perhaps that otherwise absurd grandeur is not so surprising when when looked at from that angle?
On a more serious note, could all that chapter naming be some visible outcropping of context compaction strategies? "Condense the conversation history into a summary". Not really surprising that it comes up with these "cute" headlines. Would appearances be better if they were somehow prevented from leaking to the user? Sure. Would results be better? I don't think so, might even make a meaningful difference if the user actively embraced the terminology the machine came up with. Ouch.
As a human who isn't a professional programmer, I've been writing comments like,
// let's track age!!
// this is harder than you'd think as I with totally impressive
// foresight didn't add age to the raw data.
//
// More honestly, I didn't want to add age to the astro data as that's
// a calculation that can change depending on how you slice it.
//
// Hence we need to figure out their age first.
I think this passes. In general "why" over "what". Give context to why something is made like it is (when seeming convoluted or strange). Sometimes I think one can give historical facts for really hairy hard to fix issues that have seen multiple iterations. But LLMs don't see these nuances. They frequently smuggle in completely irrelevant details in comments, e.g. including details from the given task context, not understanding what is relevant for the code module as a whole.
Edit: For API comments it's "what" of course, detailing the workings and contracts of the exported method, function or type, so one doesn't have to read the code to figure out how to use it.
I'm mostly writing code for myself, but it's a project that'll end up being public and it'll be available for others to do whatever they want with. Does that change the answer?
Far too often the answer has been that it doesn't matter, because the reason you stopped using Jira is the company stopped sending paycheques.
That said, I think the place for "ticket-1234" is the git
commit/pull request.
Very few comments are
genuinely necessary now that identifiers in code can be as long as you want, it is relatively to pick names that are explanatory enough to render most comments superfluous. 1% exceptions for unusual algorithms. (You're using named consts/enums rather than magic numbers, yes?)
personally it's fine and I've thanked myself many times for overly detailed comments coming up to some from 8 years ago and thinking how tf was I so smart/stupid (depending on the context)
This one drives me nuts, especially because I divvy up plan documents into such granular sub chunks and Ralph loop over them, I get nonsense commit messages and comments like “PLAN-5.1.A.d.42 load bearing reassertion” unless I AGENTS.md to hell and back… and still end up having to manually reject 5-10% of commit messages because the agent simply forgets AGENTS.md instructions until reprompted.
Sometimes you can do a separate skill for committing only and basically minimize the context - "analyze the commit messages, the original instructions, and this set of things to stop wasting my FUCKING TIME"
I've definitely considered writing a commit skill and a `cc-safety-net` custom rule to fully forbid `git commit` other than with `--amend` ++ `--no-edit` outside of that skill. Hm, maybe that's a task for an upcoming weekend.