web007

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.

Reminds me of microwaves - one of the early uses of microwave heating was to reanimate frozen hamsters:

https://en.wikipedia.org/wiki/Microwave_oven#Discovery

Odds for N tickets as odd(N):

odd(0) = 0

odd(1) = X, so odd(1) / odd(0) = +Inf increase in odds of winning vs 0

odd(2) = 2X, so odd(2) / odd(1) = 2x increase in odds of winning vs 1

It's a computer based on BSD, but with no WiFi, no BT, no screen, and no ability to play movies or games or music. And it's all programmed in C - not C++ or Rust anything similarly memory-safe-ish.

So RPi, but more vague and vulnerable and less useful. And maybe more expensive?

A) "surely nobody has ever thought of [this] before]" says person who hasn't read https://xeiaso.net/shitposts/no-way-to-prevent-this/

B) It's a spin on The Onion headline about school shootings.

You mean like https://cdimage.ubuntu.com/releases/24.04/release/ubuntu-24.... ?

Yes, absolutely. Paychovisual encoding can only do so much within the constraints of H.264/265.

Throwing away 3/4 (half res) or 15/16 (quarter res) of the data, encoding to X bitrate and then decoding+upscaling looks far better than encoding to the same X bitrate with full resolution.

For high bitrate, native resolution will of course look better. For low bitrate, the way H.26? algorithms work end up turning high resolution into a blocky ringing mess to compensate, vs lower resolution where you can see the content, just fuzzily.

Go get Tears of Steel raw 4K video (Y4M I think it's called). Scale it down 4x and encode it with ffmpeg HEVC veryslow at CRF 30. Figure out the bitrate, then cheat - use two-pass veryslow HEVC encoding to get the best possible quality native resolution at the same bitrate as your 4x downscaled version. You're aiming for two files that are about the same size. Somehow I couldn't convince the codec to go low enough to match, so I had the low-res version about 60% of the high-res version filesize. Now go and play them both back at 4K with just whatever your native upscale is - bilinear, bicubic, maybe NVIDIA Shield with it's AI Upscaling.

Go do that, then tell me you honestly think the blocky, streaky, illegible 4K native looks better than the "soft" quarter-res version.

I think they are ethical but annoying if done properly, and likely give good signal as to a candidate's skill. Planning and (voluntary) time boxing to 1-2 hours make the argument stronger, as that time could equally be spent in a 1:1 synchronous interview which is worse IMO.

Leetcode-ish and strict timeboxing are awful and can't possibly provide useful signal beyond "can program in some manner". Nobody can do their best work in 1 hour timed and limited, only in the web IDE which isn't the same as their dev environment, no looking up anything, no progress on part 2 without completing part 1 and similar unrealistic restrictions.

They encourage the worst in coding. Globals, dumb temporary names, no comments and done-vs-maintainable style? Ship it. I only need to deal with this code for an hour and then it's thrown away. I'm not going to make my `important_thing_to_remember` variable anything longer than `i`, and I'm going to use `foo[0]` from that ridiculous regex I bodged together instead of splitting it up and building it from pieces where I name the capture group so Future Me can understand it.

I'd much rather have a test for 1h of reasonable work, and let me take 2h if needed to solve it and then refactor to make it maintainable.

Why would someone ever take a 40Mbps (compressed) video and downsample it so it can be encoded at 400Kbps (compressed) but played back with nearly the same fidelity / with similar artifacts to the same process at 50x data volume? The world will never know.

You're also ignoring the part where all lossy codecs throw away those same details and then fake-recreate them with enough fidelity that people are satisfied. Same concept, different mechanism.

Look up what 4:2:0 means vs 4:4:4 in a video codec and tell me you still think it's "pure insanity" to rescale.

Or, you know, maybe some people have reasons for doing things that aren't the same as the narrow scope of use-cases you considered, and this would work perfectly well for them.

The added benefit of FoldIt is to see how humans find a better answer than naive "shake" and local minima/maxima. Those methods can then be integrated into automation to get better results. So it's not just "people are better at this, let them do the work" it's "let's get people to show their work" and then use that process to make better tools.

Given this is (almost to the letter) how impersonally "layoffs" went at my company in January I think we could switch to AI severance and not lose anything of value.

The successful version of https://www.kickstarter.com/projects/antonyevans/glowing-pla...

This looks pretty cool, let's see how it goes!

Heh... I have several variants on this. My most-recent version is basically the diametric opposite of yours, make the least-readable passwords possible.

https://github.com/007/dotfiles/blob/439ba7ff1d1f6dc01c4b792...

I need to update the word list for this year, but same: https://007.github.io/tnetennba/

The good news is that it works both ways! The content is terrible -> Google demotes and/or people stop reading -> shareholder value decreases -> company disappears.

Problem solved.

Effort is not a measure of quality or value in art.

Remember:

Duct tape + banana + wall + 3 minutes = incredibly valuable and controversial art.

Me taking a year to paint a detailed depiction of a bowl of fruit = worthless, terrible art.

Results are what people care about, not effort.

Most likely someone stopped paying the AWS bill. If you `curl -k` to avoid the HSTS problem you see that CloudFront and/or lambda aren't working either.

As for "a British accent". Would an American say there's "an American accent"?

Of course, just the same as British. "American accent" for foreigners usually means "Southern Foghorn Leghorn" e.g. Daniel Craig in Knives Out, but can also mean New York, Boston, Chicago, Dakota (aka Fargo) or some other variation. To Americans it really means "unaccented" Midwestern English, aka broadcast (radio or TV) voice.

Americans know "American accent" from "British accent" by the same standard, the British "unaccented" voice is called RP and sounds posh or overly fancy to most Brits, but Americans don't distinguish RP from Cockney, Yorkie, Jordie or any of the other variants. RP is the broadcast voice.

To be clear: I used to be the same. "British" was one accent that Michael Caine, the Queen and Chris Ramsay all spoke. (For Americans: "Robert DeNiro, Harrison Ford and Dolly Parton have one accent" is equally wrong and hilarious.)