> You can either seek understanding or seek blame, but not both at once.
This is the first I've heard this statement (not necessarily the idea), but I found it incredibly beautiful in it's simplicity - thanks for sharing!
Are there origins to this that you're aware of? With some searching I found some adjacent thread lines to stoicism and Buddhism, but nothing quite the same.
I (think I) got it from ReinH on birdsite (before everyone left and moved to mastodon and Bluesky). He also gave a lot of talks on blameless postmortems and culture and general SRE stuff. This is one talk but not sure if it touches on the origins https://m.youtube.com/watch?v=KXrsvLMqF1Q
Is it even remotely appropriate to blame without first understanding? In which case, doesn't this perspective completely rule out the possibility of any appropriate blame?
> Is it even remotely appropriate to blame without first understanding?
Yet, blame is easy and satisfying and true understanding requires empathy and is hard and often unsatisfying.
The term "understanding" is fractal and infinite. Therefore
Its 100% reasonable to find a stopping point and say "I blame you" (or, as you point out, otherwise, no one would ever be allowed to assign blame).
My comment is more about intent. The "seeking" word weights heavy. Many commenters are not seeking understanding, they are seeking satisfaction. Validation. The author of the post could have stopped much sooner if they were seeking blame, they could have chosen to build a caricature to heap more judgement upon. But they chose a more nuanced and exploratory path.
Even if the end result is blame or judgement. It's important that the purpose of the journey is clear. True understanding requires empathy, and it's really hard to empathize with someone you're actively trying to judge or vilify.
I think it's fair to call out a dark pattern for account deletion (which, for better or worse, is common practice) - but the data training and data retention thing can both be disabled...I was much more surprised that they DIDN'T train on data as long as they did, when every other LLM provider was sucking in as much data as they could (OpenAI, Google, Meta, and xAI - although Meta gets a pass for providing the open-weight models in my head).
Anthropic has made AI safety a central pillar of their ethos and have shared a lot of information about what they're doing to responsibly train models...personally I found a lot of corporate-speak on this topic from OpenAI, but very little information.
If I could offer another suggestion from what's been discussed so far - try Claude Code - they are doing something different than the other offerings around how they manage context with the LLM and the results are quite different than everything else.
Also, the big difference with this tool is that you spend more time planning, don't expect it to 1 shot, you need to think about how you go from epic to task first, THEN you let it execute.
The trick shouldn't be to try and generate a litmus test for agentic development, it's to change your workflow to game-plan solutions and decompose problems (like you would a jira epic to stories), and THEN have it build something for you.
In fairness, if this was in a relational data store, the same code as above would probably look more like...
SELECT DISTINCT authors.some_field FROM books
JOIN authors ON books.author_id = authors.author_id
WHERE books.pageCount > 1000
And if you wanted to grab the entire authors record (like the code does) you'd probably need some more complexity in there:
SELECT * FROM authors WHERE author_id IN (
SELECT DISTINCT authors.author_id FROM books
JOIN authors ON books.author_id = authors.author_id
WHERE books.pageCount > 1000
)
SELECT * FROM authors WHERE author_id IN (SELECT author_id FROM books WHERE pageCount > 1000);
But I think you're missing the point. The functional/procedural style of writing is sequentialized and potentially slow. It's not transactional, doesn't handle partial failure, isn't parallelizable (without heavy lifting from the language--maybe LINQ can do this? but definitely not in Java).
With SQL, you push the entire query down into the database engine and expose it to the query optimizer. And SQL is actually supported by many, many systems. And it's what people have been writing for 40+ years.
But I don't think I missed the point, the original text talks about measuring complexity as a function of operators, operands, and nested code. The true one to one mapping is more complex than the original comment I replied to
This ended up being the preferred pattern we moved into.
If, like us, you were passing the object between two applications, the owning API would serialize the enum value as a String value, then we had a client helper method that would parse the string value into an Optional enum value.
If the original service started transferring a new String object between services, it wouldn't break any downstream clients, because the clients would just end up with Optional empty
How that works when you need to distinguish between "no value provided" and "a value that is not in the list" - in some applications they have different semantics.
You could treat it as an nullable Option<SomeType>.
In practice, as it relates to enums, I don't usually see 'no value provided' as a frequently used case - it's more likely that 'no value provided' maps to a more informative 'enum' value
Love this share, I just watched the 1955 vs 1957 Royal Quiet Deluxe video. Learned a couple of fascinating things:
1. 1955 model did not have the number "1" or the "!" - as I guessed, you can get the 1 with a lower-case L. But the exclamation point stumped me - turns out you had to use apostrophe, then backfeed a character, then use a period over the same space to recreate the "!".
2. Different typewriters had different typesets that could result in dramatically different script lengths for writers. It forced one of the screenplay writers of Star Trek to have to tighten up his script substantially after they realized it was too long.
The character set we got with the advent of computer keyboards is the result of a lot of random selection since the creation of the first keyboards (both the QWERTY typewriter but also the ETAOIN Linotype keyboard and Monotype’s keyboarding unit, not to mention the earliest input keyboards based on piano keys).
This is the first I've heard this statement (not necessarily the idea), but I found it incredibly beautiful in it's simplicity - thanks for sharing!
Are there origins to this that you're aware of? With some searching I found some adjacent thread lines to stoicism and Buddhism, but nothing quite the same.