I think you misread the post. He's saying that his ignorance was great, and maybe we should go back towards that.

I don't think Tumblr was particularly influential on the neighbors aspect. It never reached that kind of broad base. Twitter did though. Unless you just mean social media broadly?

It wasn’t ignorance, but tolerance.

I wasn’t referring to social media or his role in it at all except as a participant.

Like you, I dislike the "talker" role for people on IC ladders. I often encourage those people to switch to Director+ roles.

The flip side is people who get and stay too far into the weeds. Solving little problems here and there is a great way to keep your finger on the pulse of what's actually going on.

But if you get totally bogged down in details, you are probably avoiding your leadership responsibilities. You should be observing the structural or strategic opportunities, and then dragging the org(s) in that direction.

Sometimes you do that by writing some code to prove a point, other times you do it by getting the nearest VP to take something on as a commitment. For me, personally, I find that the style of work waxes and wanes. Sometimes I get almost no code committed in a month :(. Other times, I get to go off and do some work that nobody else would have done.

I prefer the latter, but I respect that my job requires the former. Many of the people who you see spending all their time talking believe that's the most responsible use of their time. They might not personally prefer it!

This is one of the meandering arguments in the post. The whole executive team, in fact. But it doesn't compare how much other executives are making, etc.

I made a single, coherent argument. If you're seeking cost savings, he's a 14M liability, and easily replaced at lower cost.

I feel there's something in this article, but the meandering really ruins it. Either way, it's obvious that no earnings call would explain the metrics or decisions behind a layoff. But at 7% this is well within "Eh, we want to try a performance layoff and hope we get a better 7% of new hires".

It is too bad that people aren't more direct about this. But if folks remember Meta/FB's attempt at saying they did performance-based cuts, people ripped into them for labeling all the fired personnel as un-hireable. Earnings calls are heavy lawyered and regulated, so there's no reason to say anything.

As aek and dahart said, updating a BVH (refitting) is not expensive. If anything, it's bandwidth limited.

The challenge is minimizing the cost of (selectively) rebuilding.

The method from the paper safes both, memory bandwidth and compute time. You animate and write (to memory) a way smaller number of vertices. You update a smaller (less memory bandwidth, less compute) BVH.

That’s just another way of saying “updating a BVH is expensive therefore spend effort to minimize the amount of updating it”.

The fastest code is the code that never runs.

There’s a material algorithmic difference between rebuild and refit. Not sure if that point was clearly understood.

I get that he's maybe a bit into LLMs, but your take is pretty unfair. He's said repeatedly that as a non-native English speaker, his writing will come across a bit strangely.

If he'd said: "We all need to learn to be like Linus", would that have changed your take?

It's clear he's very respectful not only of Linus, but of all the people involved as well. He's instead using Linus's transition from full-time writing software to full-time "leading" as the point of his write up. Don't get hung up on the verbiage.

0 x inf is also NaN. It's not just division.

Do you have a larger study planned for the Fall? It definitely seems promising.

I'm curious how well you feel this worked because the subject was Statistics (objective grading) versus something more subjective like Civics or Literature.

PS - I'd say this qualifies for Show HN, too!

Do you

They were using Sonnet 4.6 for some fre form responses so that could be applied to something subjective.

But it's not clear that using Sonnet or any other LLM as a "grader" would result in the same improvement. For objective grading, you could be sure that the additional adaptive support is helping. For subjective things like writing style, literature, poetry, you end up with whatever Sonnet thinks is good (and randomly so).

It still could be better for students, but it's not obvious that it would be (or maybe not as strongly?).

And it made a classic optimization: removing New Zealand :).

In its defense, it actually asked me whether I wanted to spend my 500 bytes on more resolution for the main continents or more landmasses, and I opted for the former. You can blame me for that, not Claude :)

This is nice work, but I found the bug finding example to be weird:

> One such bug was in the sign function for zigzag decoding of the datrs/varinteger library. On input Std.U64.MAX, the expression (value + 1) overflowed, causing crashes in debug mode and silent corruption in release mode—an edge case that testing and fuzzing would typically miss.

In what way would this boundary condition case be considered something that "testing [...] would typically miss"? It's certainly something that bad tests would miss or not think about, but I find that (a) careful people and (b) ML coding systems are actually really good at "oh, I should test the extreme values". Especially for things that parse user input.

I'm curious if they found other bugs that were more interesting, but found them too hard to explain quickly.

particularly "and fuzzing", yea. fuzzing generally does intentionally explore boundary values, from what I've seen. for an encoding library like this, I think it's fair to say that fuzzing is a baseline expectation for any decent code, and it almost certainly would've caught this in seconds.

--- edit

concretely, I made a very simple round-trip test with proptest, and got dozens of failures and this in less than a second:

    thread 'signed_round_trip' (50528) panicked at tests/test.rs:72:1:
    Test failed: attempt to multiply with overflow.
    minimal failing input: value = 4611686018427387904
        successes: 2
        local rejects: 0
        global rejects: 0

Maybe it's not something they would "typically miss", but, from proof by existence, it's something they sometimes miss.

It does speak to the benefits of using lean in that you don't need to be clever about the different examples you test.

Because this is garbage PR. That's it.

Every property-based testing system (invented ca. 1980) will explore boundary values. The semantics (or lack thereof) of C and C++ can make this difficult to actually test for because the compiler is allowed to say "test passed" to any input leading to UB.

Property based testing is good at generating boundary values for inputs. But for any more complicated piece of code getting boundary value coverage of interior values is an open problem that requires instrumentation feedback to understand branch coverage and value coverage of the code that got tested. It’s not an easy thing at all.

> The semantics (or lack thereof) of C and C++ can make this difficult to actually test for because the compiler is allowed to say "test passed" to any input leading to UB.

I get what you are saying but does this actually apply to a test? If the code under test is in one compilation unit and the test harness in another and they are linked together then the UB optimization issue ends at the API boundary and can't possibly make the test pass ..?

It's definitely less likely with that technique (in practice!), but still very possible, via e.g. ODR violation or even the classic SIOF.

So, ideally you'd want each separate test case to be compiled separately, but even then you wouldn't be safe! ... because any UB in that test (or the code it's testing!) could lead to a random pass.

UB is good in some ways, but other ways it's really really bad.

EDIT: I will say: If you have a UBSAN turned on for testing, etc. you're reasonably safe... but not fully. There's a lot of stuff they don't catch because it's essentially impossible.

Yes, it's basic QA. If tests missed this kind of thing, they would be of much more limited use than we generally expect them to be. It raises questions about the authors' background.