koreth1

Long comments, well-informed comments, comments they don't agree with, comments praising something from a specific company or country, the list goes on. It's basically impossible to actively participate in online discussions these days without being accused of being a bot at least occasionally.

I miss the days when I was allegedly just a shill. Being a shill pays way better than being a bot, so I had something to aspire to.

Good catch! I misremembered his model. He actually uses an iPhone 13 Mini, which definitely counts as small (by modern smartphone standards, anyway).

My dad is 87 and I'm seriously thinking about buying him one of these. He wants a phone that will fit in his pocket, but his vision isn't great so he has the text size bumped up pretty high. Right now he's using an iPhone 15. Large text size on a small-form-factor phone, it turns out, makes a fair number of apps nearly unusable. For example, it's super common to see a dialog box pop up where the "OK" button is pushed off the bottom of the screen by the text, leaving you with no way to dismiss it. I frequently get tech-support calls from him that end up boiling down to that problem, and it makes using apps a pretty frustrating experience for him.

A device that fits in his pocket and that he can still hold in one hand when he's using it as a phone, but that has enough screen real estate to run apps in large-print mode without constantly breaking UI designs, would meaningfully improve his life.

> For one, rolling luggage is usually a mistake for anyone who's not flight crew.

I used to travel with just a soft carry-on bag that converted into a backpack. It was great to just pick it up and go, and not have to worry about constantly extending and retracting the handle or bracing the bag so it wouldn't roll away on a hill.

But around the age of 50, my back informed me in no uncertain terms that those days were behind me. Now I let the wheels on my luggage carry the weight.

Honestly? I looked it up on the glossary page of the company wiki and didn't feel much of anything about having to learn it.

At the time I didn't know what "Global Biodiversity Information Facility" referred to either, or why it was relevant to my team. Even without the acronym, I still would have had to go look it up or ask about it if someone used it with the expectation I was already familiar with it. I don't think the acronym had any significant effect on my experience of learning the concept.

> For instance most people don’t know that even though both CAP and ACID contain consistency, they do not refer to the same idea.

But wouldn't people still be unaware of the difference in meaning if the acronyms were spelled out? The word "consistency" appears in both names, with no indication that its meaning is context-dependent. I don't think you can lay the blame for this one at the feet of the acronyms.

I think context and audience matter a lot. The post seems to mostly be talking about acronyms in the context of writing that's aimed at a public audience, but a lot of acronym use is aimed at a much more targeted audience.

For example, I work on a product that pulls data about plant species from various data sources. I'm not about to type "Global Registry of Introduced and Invasive Species" or "Global Biodiversity Information Facility" everywhere; everyone on my team, and pretty much anyone working in this problem space, knows them as "GRIIS" and "GBIF." If I wrote the names out every time, it'd probably be less clear to my audience: they'd most likely have to reconstruct the familiar acronyms in their heads to follow what I was talking about.

For me it was Suno, not any of the coding tools. I prompted it to write a song about my family's little dog, told it a few things about the dog, and it came back with a K-pop-style anthem that had a super catchy melody and lyrics that made my wife and me laugh out loud.

Writing code to spec is one thing, but creating art was always supposed to be what separated us from machines. (I suppose I need to preemptively acknowledge the "it was machine-generated so by definition cannot be art" point of view.)

> sbx - no docker desktop required

I usually run OrbStack instead of Docker Desktop on my Mac (Docker Desktop is installed on my system, just not running) and when I tried running sbx, it ignored my OrbStack setup and auto-launched Docker Desktop's daemon instead.

If it's possible to bypass that and tell sbx to use OrbStack instead, I'd love to know how.

It actually did automatically break the work up into chunks and launched a bunch of parallel workers to each handle a smaller amount of work. It wasn't doing everything in a single instance.

The problem wasn't that it lost track of which changes it needed to make, so I don't think checking items off a todo list would have helped. I believe it did actually change all the places in the code it should have. It just made the wrong changes sometimes.

But also, the claim I was responding to was, "I start with a PRD, ask for a step-by-step plan, and just execute on each step at a time." If I have to tell it how to organize its work and how to keep track of its progress and how to execute all the smaller chunks of work, then I may get good results, but the tool isn't as magical (for me, anyway) as it seems to be for some other people.

I wish I had this kind of experience. I threw a tedious but straightforward task at Claude Code using Opus 4.6 late last week: find the places in a React code base where we were using useState and useEffect to calculate a value that was purely dependent on the inputs to useEffect, and replace them with useMemo. I told it to be careful to only replace cases where the change did not introduce any behavior changes, and I put it in plan mode first.

It gave me an impressive plan of attack, including a reasonable way to determine which code it could safely modify. I told it to start with just a few files and let me review; its changes looked good. So I told it to proceed with the rest of the code.

It made hundreds of changes, as expected (big code base). And most of them were correct! Except the places where it decided to do things like put its "const x = useMemo(...)" call after some piece of code that used the value of "x", meaning I now had a bunch of undefined variable references. There were some other missteps too.

I tried to convince it to fix the places where it had messed up, but it quickly started wanting to make larger structural changes (extracting code into helper functions, etc.) rather than just moving the offending code a few lines higher in the source file. Eventually I gave up trying to steer it and, with the help of another dev on my team, fixed up all the broken code by hand.

It probably still saved time compared to making all the changes myself. But it was way more frustrating.

The biggest thing tying my team to GitHub right now is that we use Graphite to manage stacked diffs, and as far as I can tell, Graphite doesn't support anything but GitHub. What other tools are people using for stacked-diff workflows (especially code review)?

Gerrit is the other option I'm aware of but it seems like it might require significant work to administer.

> otherwise the PRs just keep piling

Good news! You can't create new PRs right now anyway, so they won't pile.

Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.

This is an interesting way to look at it because you can kind of quantify the tradeoff in terms of the value of your time. A simple analysis would be something like, if you value your time at $60/hour, then spending an additional $30 in credits becomes a good choice if it saves you more than a half-hour of work.