koreth1

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.

> I've seen people who prefer to say "hey siri set alarm clock for 10 AM" rather than use the UI. Which makes sense, because language is the way people literally have evolved specialized organs for.

I don't think it's necessary to resort to evolutionary-biology explanations for that.

When I use voice to set my alarm, it's usually because my phone isn't in my hand. Maybe it's across the room from me. And speaking to it is more efficient than walking over to it, picking it up, and navigating to the alarm-setting UI. A voice command is a more streamlined UI for that specific task than a GUI is.

I don't think that example says much about chatbots, really, because the value is mostly the hands-free aspect, not the speak-it-in-English aspect.

I'd sort of roughly approached this technique with my own channel organization over time without thinking about it systematically, but this is a helpful crystallization of what I'd been trying to achieve. I'm glad this was posted.

Definitely agree with others that Slack needs a richer selection of notification mechanisms, both for new content in channels and for mentions. For mentions, there's no level between "I demand immediate attention from this person" and "the characters that make up this person's name happen to be in the text of my message."

> I'll start by saying I'm skeptical of the answer and ask it to state its reasoning.

How do you tell if it's actually stating the reasoning that got it to its answer originally, as opposed to constructing a plausible-sounding explanation after the fact? Or is the goal just to see if it detects mistakes, rather than to actually get it to explain how it arrived at the answer?

When I was living in China I got used to crossing large streets one lane at a time. Pedestrians stand on the lane markers with cars whizzing by on either side while they wait for a gap big enough to cross the next lane. It's not great for safety, to put it mildly, but the drivers expect it and it's the only way to get across the road in some places. I was freaked out by it but eventually it became habit.

Then I came back to the US and forgot to switch back to US-style street crossing behavior at first. No physical harm done, but I was very embarrassed when people slammed on their brakes at the sight of me in the middle of the road.

As a satisfied customer of yours, the prospect of having to give up Graphite is the main thing keeping me from giving jj a try at my day job.

Ironic, since if there are a bunch of people in my boat, the lack of us in jj's user base will make it that much harder for jj to cross the "popular enough to be worth supporting" threshold.

I didn't get a diagnosis at Kaiser SF, but I was able to get meds through them. Maybe this will be of use to you.

I was diagnosed by a non-Kaiser psychiatrist I found on my own. After trying different prescriptions, we eventually settled on Concerta. I stayed on that (and continued seeing the same psychiatrist, whose service I paid for out of pocket) for about 4 years.

Then my psychiatrist had some family stuff come up and had to move out of California. Since she was no longer going to be licensed here, she couldn't keep prescribing my meds to me. But she was able to write a letter describing my situation and laying out how she'd arrived at the prescription I was on, with particular emphasis on the fact that she hadn't seen any evidence of misuse on my part. I gave that letter to my Kaiser primary care doctor, who agreed to take over the prescription. After that I was able to get my meds from Kaiser each month without any issues.

I imagine this kind of setup depends on your primary care doctor; I may have just gotten lucky with mine.

This looks really useful! Wish I'd had something like this when I was learning Mandarin.

I'm curious what determines whether or not you add a given language to the list. DeepL and Claude, at least, have usable translation ability in more languages than the app currently supports. Is there a lot of manual effort required for each language, or do you want to keep the list limited just to avoid overwhelming users?

This is maybe not in the spirit of OP's question, but I do it by having successfully made the case early in my company's lifetime that we should open-source most of our code.

Nearly every piece of code I write at work is part of one of those public, Apache-licensed code bases. Which means I spend most of my time working on OSS.

Are these projects the kind of thing anyone else will ever use? Probably not, so long as the company stays in business. The business case my team made was focused on transparency and long-term viability: our customers can see exactly what we're doing with their data and how our systems work, and if we go under, they have a realistic way to continue using our software. This hasn't ended up being a huge selling point, but customers have definitely mentioned it as one of the things they liked about us.

On some level, though this isn't quite what the person you're replying to was saying, it doesn't really matter whether AI actually can do any entry-level jobs. What matters is whether potential employers think it can.

To impact the labor market, they don't have to be correct about AI's performance, just confident enough in their high opinions of it to slow or stop their hiring.

Maybe in the long term, this will correct itself after the AI tools fail to get the job done (assuming they do fail, of course). But that doesn't help someone looking for a job today.

> That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal.

Me either, but I have a hunch about why.

Are you a fast reader?

I am, at least compared to the population at large. And one of the reasons I can't stand video as a format for learning about coding topics is that it is so frustratingly slow compared to my reading speed. To get anywhere close, I have to crank the playback speed up so high that I start having trouble understanding what the presenter is saying. That's on top of other things like poor searchability and no way to copy-paste code snippets.

The decline of reading skills, at least in the US, is pretty well-documented. And my hunch is that for the increasingly large number of people coming into the industry who don't read quickly or well, the efficiency of learning from videos is closer to parity with text. What's more, I suspect there's high correlation between lower reading skills and dislike of the act of reading, so videos are a way to avoid having to do something unpleasant.

I have no solid evidence to back any of this up, but it seems at least as plausible to me as any other explanations I've run across.

I don't have aphantasia (I can picture people and things if I want to) but unless I'm building a user interface, my thinking is completely non-visual when I'm programming or thinking about systems or data.

When someone asks me to draw an architecture diagram or a diagram of our production infrastructure or whatever, I am very slow at it and the result is usually middling at best, because my mental model of those things has no geometric or spatial component at all.

To the article's point, I've can't recall ever finding a visualization of my actual code or architecture that helped me work through a problem. When I've tried, it has always just slowed me down because I constantly have to map back and forth between the picture and the native non-geometric version in my head.

That's not to say I never use any kind of visualization. Graphical representations of things like profiling results are convenient and useful to me. But they tend to be more like representations of numeric data than representations of systems or code.

The performance on programming tasks is impressive, but I think the limited context window is still a big problem.

Very few of my day-to-day coding tasks are, "Implement a completely new program that does XYZ," but more like, "Modify a sizable existing code base to do XYZ in a way that's consistent with its existing data model and architecture." And the only way to do those kinds of tasks is to have enough context about the existing code base to know where everything should go and what existing patterns to follow.

But regardless, this does look like a significant step forward.

Same experience. When I was a little kid, I thought the high-pitched whine was just what “silence” sounded like.

Wouldn't maintaining that standard make it effectively impossible to ever find any manager able to lead a team whose members have deep specialized expertise, especially if the team has expertise in more than one area?

One place I think it can be useful is in shortening the feedback loop for learning outside the classroom.

As an example (not K-12!) my wife is learning Japanese. She's taking a class and the teacher gives her homework, but she also studies on her own, including doing exercises in the textbooks beyond the ones the teacher assigns.

Sometimes she'll answer a question, look it up in the answer key, and find she got it wrong. Previously, she had to wait until the next class and find time to ask the teacher to help her understand her mistake.

But I showed her how to use the ChatGPT phone app to get an explanation right away. She doesn't even have to type it in: just take a picture of the quiz (which is all in Japanese, not English) and ask, "Why is the answer to question 7 'C' instead of 'D'?" And she gets back a detailed explanation of the differences between the two answers and why "C" is a better choice, complete with fresh example sentences and breakdowns of what they mean.

Hallucinations are a risk: she could get back a bogus explanation. So far, that hasn't happened, though. She isn't a total beginner and knows enough to be able to tell whether the explanation makes sense. Each time, her reaction has been something like, "Oh, right, I forgot about that," not, "What? Never heard of that." She also tried it on a couple of questions she'd run by her teacher previously, and got back roughly the same explanations the teacher had given her.

In theory she could just ask it for the answer rather than for an explanation of why her answer was wrong, and it would happily give her a usually-correct response. In her case, that's not a problem because her only goal is to actually learn the language. Cheating would serve no purpose at all. But for a K-12 student who mostly cares about getting a good grade, obviously that's going to be a big temptation.

I had a similar experience learning Mandarin as a native English speaker in my late 30s. I learned to pronounce the ü sound (which doesn't exist in English) by getting feedback and instruction from a teacher about what mouth shape to use. And then I just memorized which words used it. It was maybe a year later before I started to be able to actually hear it as a distinct sound rather than perceiving it as some other vowel.