bgoated01

Huh, I've had many times when `codex /review` comes back satisfied on the first shot, both with handwritten and LLM-assisted PRs.

We use only one round of LLM review, and have discussed as a team still assessing recommendations, not just accepting everything blindly. So somewhere in the (0,1] rounds of review. Sounds like our preferred ratio of human to LLM involvement is different than yours, though.

I imagine in soil with any amount of rocks at all, ground penetrating radar and seismology are going to detect the rocks better than they would worms. I wonder if the worms make enough "noise" or vibration to be detected passively? I imagine not, but that seems like it has at least as much potential as the active detection methods for this case.

My kids are learning on Scratch. 10 and 9 years old, been doing it for a few years at this point. The older one has had the opportunity to switch to Python but keeps going back to Scratch. He can make less trivial things than I used to make with Mark Overmars' GameMaker when I was a teen, and I'm now a C++ developer. So it would seem like a high possibility. He's done pathfinding algorithms, raycasting, file loading/saving, etc. The other kid likes it for creating artwork.

But what if the genie instead offered (or threatened) to give _everyone_ the answers to everything you'll ever discover in your career, including your boss, your competitors, etc?

Is the telescope design available anywhere for hobbyists to build? I can't seem to find anything in the article or in a separate search. I'd be interested in perhaps putting one of these together to do radio astronomy with my kids.

> “This isn’t just a new value of the Hubble constant,” the collaboration notes, “it’s a community-built framework that brings decades of independent distance measurements together, transparently and accessibly.”

Don't love that I can't read sentences like this without wondering if an LLM was involved.

Probably the biggest purpose for me is to have something to look back on. The last time I consistently journaled before this was during the time when I dated, got engaged to, and married my wife. Granted, that was more than a line journal, but it has been really nice for us to go back and read it together all this time later. With the line journal it is more of a prompt to help me remember that time period than a detailed description. But also I guess there is an autobiographical aspect to it that appeals to me--maybe someday I'll use it to help write an actual autobiography. And if not I also like to think of it as something to leave for my kids or grandkids to read when I'm gone.

I have been doing a one-line-a-day journal for the past two years. If I ever feel like writing more I have a separate section for that, but I only ever tell myself to write the one line. It's the first time I have been able to consistently write in a journal for a very long time before I started. My entries are not nearly as "composed" as the examples here, though, just tiny highlights of what happened during the day.

Right. All it takes is for one to work out, if you have several suitable options. If some of the options are only vaguely suitable, or it comes to light through the process that some of them are not suitable at all, then it takes more than just one working out. That's what I was thinking while reading this.

If you're referring to Cubit, they license the ACIS kernel under the hood.

I notice that your application asks about willingness to relocate. Are you able to do fully remote for the right candidate?

> So much of writing is managing your own emotions. The virtue of “pseudowriting” is that it helps you preserve hope for as long as possible—hope that what you will eventually put in place of those square brackets will be good. Hope keeps you coming back: it is more pleasant and low-stakes to pseudowrite than to fix actual language into the draft; and it is less daunting to return to a document where it feels like all that’s left is for you to fill in some blanks. Do that enough times and you will, in fact, end up with something you can read top to bottom.

This describes how I write a new chunk of research code, often. I'll type along until I get to something like "oh, I'll need to calculate the foo of the widget here," and I'll just put a non-existent function call calculateFoo(widget) there until later, when I'll come back and fill it in. I feel like it keeps it manageable; I'm choosing the level of abstraction that I'm drafting code at, and I come in and fill in the details later. I hadn't connected this idea to the journal articles that I am working on; I typically feel somewhat guilty when I add a FIXME in my LaTex document, but with this framing I see now that that is probably the better way to do it than aiming for a finished paragraph from the get-go. The square brackets and placeholders also seem much nicer that the FIXME I was using. Glad to have seen this at a timely moment for me!

I didn't have time to get through the whole article today, but I did spend some time with my kids playing the Wikipedia first link game, which we enjoyed. We kept trying to find one that didn't end in Philosophy, and my youngest son said we should try Brick. Sure enough, it ended in a loop consisting of Existence and Reality.

My brother just finished building an automatic pipe organ for his Mechanical Engineering senior project. Or maybe you'd call it a street organ since it has no keyboard. It has midi input on some arduino-like device, 3d printed pipes, a hand crank pump to fill the bellows, and a bunch of shift registers, relays, and solenoids (on breadboards at this point) to open the valves for the pipes. It turned out really nice, and was a hit at the project showcase. I was involved in helping him figure out the electronics and the code, though I think he threw out the code I wrote in favor of using ChatGPT. All in all, it's not a technically difficult thing to make, though I have the benefit of his hindsight at this point. Maybe I'll get him to write it up at some point.