wesselbindt

Fair point! This post is not a load bearing and accurate description of Claude's workings, it's satire.

> The way you test code cannot (and should not) be decoupled by the way in which you architect the code itself.

I'm not sure I fully understand. In my view, it's pretty evident that tests should test behavior and not structure. Coupling to implementation details is unavoidable but should be managed, and ideally minimized, to keep the test suite robust and maintainable.

Given the choice between a test suite that monkey patches out some dependency (redis, say) on a per-test basis, and one which substitutes a fake for this dependency in some centralized composition root, which one do you prefer, and why?

Thank you, I appreciate you sharing this very much! I wish I could read the entire chat, but I imagine there might be some NDA stuff in there if you talk abt real world experiences.

> Teams, em dash bla bla bla em dash have quietly bla bla bla. It's not this, it's _that_.

I find it hard to read articles where the agentic writing is this obvious. It's a distraction from the message of the text, which I'm sure is worth my time. Is there no way to stop generated writing from sounding like this?

So, I get the idea of having a layer of abstraction between your tests and the system under test. You decouple _what_ is being done from _how_ it is done, which leads to robust, easily maintained, and even more re-usable test suites. I've seen it in action, it's a great idea, I've reaped the benefits myself. Great stuff.

What I've never really understood is why some people choose natural language for the abstraction. It just seems like such an odd and expensive choice. Most of the layers of abstraction we add in our codebase are written in the programming language of choice itself, they're functions, classes, what have you. But for this one specific flavor of abstraction, folks reach for natural language.

The one potential benefit I could think of for this over a more standard DSL is that non-technical colleagues would be able to read or even write these specs. But in practice I've only seen this pan out once in my life, and that was with a more traditional DSL rather than natural language.

Is there a hidden benefit I'm overlooking?

Literally everything except the media writing non-sensationalist headlines about science.

> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?

There's probably a lot wrong with the "coding was never the hard part" take, but this quote right here shows that the author is not willing to engage with the actual idea that folks who say this are espousing. Because if the author was discussing these ideas on good faith, he'd know that the answer is obvious: there's much, much more to a software engineer's job than just coding, and that other stuff is very hard to do well, and people pay for that.

Again, I'm not saying the "coding was never the hard part" folks are right, but I really, really hate straw men.

Exactly, I feel the same way, and was surprised to see so few people pointing this out. Forest vs desert I guess.

Ok, thanks for explaining! Doesn't really explain how the wc eend expression _doesn't_ apply here (which would be hard to do, because it _does_ apply, since this is someone praising their own work, and it doesn't get more straightforwardly applicable than that), but I do really appreciate the effort.

I always thought it was common sense and just basic critical thinking to take people paid by Anthropic praising products of Anthropic with a grain of salt (and let's be clear, that's what this is), but apparently it's not.

I don't see how Claude code being a widely used product is relevant to the person who orchestrated the Rust rewrite of bun saying that the orchestration of the Rust rewrite of bun went well. Wc eend is a widely used product as well, if that helps.

Ah, for context, which I suspect you may be unaware of, Jarred (the person who said the rewrite to rust went well) is the creator of bun, and the guy behind the rewrite.

It was a commercial slogan for a toilet cleaning agent. An English equivalent would be "mr clean recommends you use mr clean". Today, it is used to point out when someone tells you they themselves delivered good work. Anytime you'd use the meme of Obama giving himself a medal, you could use this phrase.

In Dutch there's a saying, "wij van wc eend adviseren wc eend", and it fits perfectly.

They balance the budget?

It reveals the exact type of mindset that could produce an article like this. All they know is waterfall, so they see agentic coding and think: "you know what we need? More waterfall"

To create goodwill! Nefariously!

I'm nowhere near that level of experience, although I've done both as well. I'm more backend oriented. And my experience has been the opposite. When I ask for backend code, footgun after footgun appears on my screen. With frontend code, much less of an issue, as far as I can tell. Part of me believes this is because I'm less skilled at frontend, and I don't bat an eye when the LLM plops down yet another useMemo (I've since learned that this is rarely needed). But in your case this argument can hardly be made. With 25 years I trust your ability to spot a good design on either end of the stack. So then I don't know where this discrepancy comes from. Maybe my prompting skills leave something to be desired.

Would you describe yourself as more skilled at frontend engineering or at backend engineering?

I'm well aware of its context and original meaning, and I'm very happy to twist its meaning into something Kissinger would disagree with any chance I get.

You guessed wrong. As far as I know, there's no such lobby, and I find your suggestion of its existence to be antisemitic. But the pro Israel lobby is quite open and public. Aipac's spending, for example, is public knowledge, and you can look it up for yourself.

As the saying goes, it may be dangerous to be America's enemy, but to be America's friend is fatal. True in the 60s, still true today.

The idea of injecting more indeterminacy in pipelines is beyond me.

Artisanal astroturfing, using organic humans, used to be the norm. Could be that OP is an actual human doing astroturfing.

Why?

> Well, because obviously the finish line of the space race was the Moon.

So, this choice is not super obvious to me. If it was called the moon race or whatever, I'd get it. But in this case it just feels like making up rules after the fact to make sure you "win".

EDIT: I just realized you might be saying this sarcastically. I'm really bad at picking up on that sort of stuff, and apologize if that's the case.

America won the space race? The only milestone where the US got there first was having boots on the moon. Every other milestone (first artificial satellite, first organism in space, first man in space, first woman, first spacewalk, first craft on the moon) was achieved by the soviets first. Taking the one arbitrary milestone where the US did come in first and declare it the finish line feels weird as heck.

Those are not arguments, those are assertions.

I feel like this argument always boils down to explicit vs implicit. It tastes the same as static vs dynamic typing. Personally, I fall well into the explicit camp. I like when I can know stuff about a function without having to read its body, and the bodies of the functions it calls, and the bodies of the functions they call, and so on. And so, I like when I can see from the function signature that it returns an integer, or when I can see from the function signature that it might do IO.

This comes at a cost, namely that of reading five extra characters in a function signature, and I could kind of imagine (truly!) how that gets in the way for some people. There is a cost of writing the five characters as well (and like the author mentions, in a poorly designed codebase, this may have to go down the call stack), but code is read more often than written, so in a sense this is negligible.

Like the dynamic vs static typing debate, I feel like this ultimately boils down to context and personal taste, and some amount of intelligence as well. I'm impressed by the amount of stuff the dynamic typing / non-async crowd is able to keep in their working or long term memory while coding. I don't have that kind of mental bandwidth, sadly.

Having said all that, this argument is disingenuous in that it completely ignores the fact that the async keyword tells you something useful (rather than some made up nonsense like color), and most of the argument basically boils down to "if you ignore the benefits, this syntax has no benefits", and I really don't respect that as an argument.

I've been in the situation a couple of times where we had full control over choosing the frontend framework. Every time we chose React, the main argument was hirability and the fact that the engineers in question were most proficient in React. That is, inertia.

Secondly, when someone new asks me what web framework to learn, I tell them React. And the main reason, every time, is that this is more likely to get them a job, i.e., inertia.

We got here somehow. Clearly, React didn't get here purely on momentum, and must have done something less poorly than the other frameworks. But I think it's hard to deny that inertia plays a big role in its current popularity.

Seems like you dropped something:

> Disclaimer: I maintain depsguard

I was under the impression that anyone that uses the MTTR abbreviation knows enough to understand that you need to balance it with change failure rate, deploy frequency, and lead time.