web007

"Imagine a thing. Now, imagine a thing a hundred times bigger!"

It's a really weird analogy.

So much of the problem here is that the author blindly trusted the agent. They're enthusiastic juniors, not jaded seniors.

Prompt for what you want. Get your feature working, then cut: reduce SLOC, refactor to remove duplication, update things to match existing patterns. You might do these instinctively, or maybe as-you-go, but that's just style. Having a dedicated pass works just as well.

The same thing goes for my code now that did when I wrote every line by hand: make it work, then make it good, then make it manageable. Manually that meant breaking things down into small blocks of individual diffs inside a PR (or splitting PRs), checking for repetitive code and refactoring, or even stashing what I got to and doing it again with the knowledge of how things went wrong.

Agents can do the same. It's WAY easier mentally and works out better if you treat them the same way and go working -> better -> done.

> Backups stored on the same volume is an interesting glitch to avoid

The phrasing is different, but this is how AWS RDS works as well. If you delete a database in RDS, all of the automated snapshots that it was doing and all of the PITR logs are also gone. If you do manual snapshots they stick around, but all of the magic "I don't have to think about it" stuff dies with the DB.

zstd beats gzip on both speed and size, for every compression level.

If you need compatibility then gzip (pigz) or zip (7z) or bz2 (pbzip2) are the best of worse outcomes, but for Pareto front optimal speed and size you want zstd.

`rclone` with AWS credentials. Go make a bucket and a key that can read/write to it.

Set up your config to exclude common non-file dirs, or say "only `/Applications` and `Home` and that's about it. If it's a file then it's a file, and it will be synced up.

There's a poop symbol on the bottom right, click it to see ways to communicate.

I was surprised to learn the random messengers are other humans!

Curation is probably a good idea, but keeping context is probably a better idea.

The referenced "I don't keep history" philosophy is madness. You won't know what thing would have been useful to keep until you need it $later. Sure, you'll write down some good stuff and maybe alias it.

That's fantastic, do more of that anyway.

Don't pretend you're going to do that for every trick or gotcha you encounter, and don't think you're going to remember that one-off not-gonna-need-it thing you did last week when you find that bug again.

My local history is currently 106022 lines, and that's not even my full synchronized copy, just this machine. It's isolated per-session and organized into ~/.history/YYYY/MM/machine_time_session hierarchy. It has 8325 "git status", 4291 "ll", 2403 "cd .." and 97 "date" entries which don't matter. Literal/complete entries, not including variations like "date +%Y%m%d" which are separate. I can ignore them, either by grepping them out or filtering mentally, but something as benign as "cd .." is INCREDIBLY useful to establish context when I'm spelunking through what I did to debug a thing 2 years ago.

The even better version of both of these variants is to keep everything AND curate out useful stuff. That whole history (4 years locally) is 10MB, and my entire history compressed would be less than a megabyte.

Edit: just realized who posted this, I overlapped with Tod at my first gig in Silicon Valley. Small world!

> LLMs are great for junior, fast-shipping devs; less so for experienced, meticulous engineers

Is that not true? That feels sufficiently nuanced and gives a spectrum of utility, not binary one and zero but "10x" on one side and perhaps 1.1x at the other extrema.

The reality is slightly different - "10x" is SLoC, not necessarily good code - but the direction and scale are about right.

I've had my "2038 consulting" sites since Feb 2011, but someone got epochalypse dot com registered August 2007.

> Storage is cheap, bandwidth is cheap, so who cares?

This is a ridiculous assertion.

They're both cheap in the commercial sense, but neither cheap nor infinite in the UX sense. Time and space matter in the real world.

Google wouldn't have created WebP if there was no tangible, measurable cost benefit to using it over some alternative. Same goes for H.264 or HEVC or AV1, at scale bandwidth and storage are far from cheap. See the article on the FP today about Google's double-digit EXAbyte storage clusters with 50TB/s read volume each as a real-world example, there's nothing cheap about that.

Look up "CV dazzle" for the equivalent in the modern age, makeup effects to avoid facial detection / recognition.

> As an analogy, driving a car is dangerous. Whenever I drive, I could easily kill someone. But the government doesn’t force me to submit a driving plan any time I want to go somewhere. Instead, if I misbehave, I am punished in retrospect. Why don’t we apply the same policy to research?

"We" decided that Tuskegee was bad enough that it should be stopped before harm is done, and that there is no appropriate or sufficient "punish[ment] in retrospect" for the fallout.

The government makes you get a license to drive at all, then "drive a Pinto" versus "drive a Trabant" are similar enough that they don't require more info. They require you to get different licensure to drive a bigger truck where you could potentially cause more harm, or to drive an airplane. In this analogy the IRB is the DMV/FAA/whatever, and you're asking for permission to drive a tank, a motorized unicycle, a helicopter, an 18-wheeler or a stealth fighter. You don't get a Science License rubber stamp because that's like getting a Vehicle License - the variation in "Vehicle" is big enough that each type needs review.

Every time you get one of those surveys rank them at zero, then add "Net Promoter Score is a flawed vanity metric and shouldn't be used for business purposes" in the comment box. Sometimes I link the Wikipedia NPS "Criticism" section as well.

Most places don't care about the results from an actual customer service perspective. The above gets crickets, not even an auto responder.

For companies that do care (tiny startups, mostly) I've gotten IMMEDIATE personal email responses from CEOs and founders asking what they can fix for a zero NPS. That's a great place to link the criticism section if not done previously, and to provide useful, raw feedback on what you love/hate about their products.

It's very likely zero or positive impact on the decompression side of things.

Starting with smaller data means everything ends up smaller. It's the same decompression algorithm in all cases, so it's not some special / unoptimized branch of code. It's yielding the same data in the end, so writes equal out plus or minus disk queue fullness and power cycles. It's _maybe_ better for RAM and CPU because more data fits in cache, so less memory is used and the compute is idle less often.

It's relatively easy to test decompression efficiency if you think CPU time is a good proxy for energy usage: go find something like React and test the decomp time of gzip -9 vs zopfli. Or even better, find something similar but much bigger so you can see the delta and it's not lost in rounding errors.