MoreQARespect

I had a similar experience when I tried to search through reviews on amazon on the mobile website.

The search box is gone and you're supposed to ask Rufus now.

There are plenty of alternatives for git hosting. The last thing which needs to be migrated before we get an exodus off this vibe coded monstrosity is reputation (i.e. github stars) which are inherently sticky.

I guess that was google wave and yea it was a horrorshow.

I had hoped that something useful would come out of blockchain technology that would allow for a better messaging protocol that was spam resistant, e2e encrypted and decentralized by design but I didnt see anything.

Email can't really change much. The protocol is too old.

It would be better if we came up with new protocols that solve the email messaging problems and then gradually wean ourselves off email rather than trying to "fix" email.

In a sense this is already happening although instead of migrating to open protocols which solve the email problems we're migrating a lot of messaging to walled gardens which solve the problems (e.g. WhatsApp).

I don't think so. Natural language is vague and repetitive.

I used hitchstory (YAML based stories) for doing this coz it's terse and typed.

I've tried using cucumber before and it reminds me of COBOL - which also had the same idea of making code more accessible via a "natural language-ish" interface.

>This is the problem: your judgement is biased. You think it was a good idea, but in reality, you have no real idea if it was or not.

My judgement is based upon my experience trying it both ways many times over the course of decades.

>To avoid over-building, the solution is not to invent a rule that says "just don't build".

It isnt a rule that says dont build what you need now. It is a rule that says dont try to anticipate what architectures or abstractions might be needed in the future.

>Again, you cannot know if it is worse or not.

I used to think like you when I was more junior (most do), so it's not like I dont have a lot of practice thinking that YAGNI applied only sometimes.

It was hard experience that taught me that it was pretty universal.

It's predicting that you will predict wrong frequently enough to make it not worthwhile predicting at all.

I apply the same logic at slots: the way to win is not to play.

>Creating abstraction for a code that was designed without being compatible with these abstraction has a huge cost

I have never found it more expensive to create an abstraction after following the rule of 3.

Indeed, ive always noticed that abstractions which are front loaded are nearly ALWAYS worse than abstractions built with hindsight.

>As I've said, nothing is all white or all black. The problem with YAGNI is the developers think it's all white

We think you're playing slots and remembering only the wins, believing that you're just naturally talented at predicting the future.

Ive seen this attitude in hundreds of devs. They all think theyre uniquely able to anticipate the code base's future needs.

>Building speculative structure can be a forcing function to establish requirements

Sure, if you're doing it as a spike but if you're not throwing the code away then it functions as a forcing function for creating slop.

YAGNI is simply a tacit recognition that you can't predict the future with any reasonable level of certainty. The reason it is controversial is that some devs truly believe that they can predict the future with all the self assurance of a grandma sitting in front of a one armed bandit in vegas. So, they will:

* Create generalized functions where a specific one would have done.

* Create abstractions for something that will never be needed in the end.

* Create abstractions for something that will be needed but not in the form they initially expected.

It is not about avoiding refactoring. That misses the point entirely. Refactoring cleans up code mess that exists NOW - creating abstractions for somehting that exists NOW.

This study seems to be mainly about the value of vibe coded tests and not at all about TDD.

Perhaps unsurprisingly it found that vibe coded tests suck. As a card carrying member of the "church of TDD" (I do think it is practical), this is an empirical result I certainly would agree with.

yes, there is some yak shaving necessary to make writing tests possible.

There is often a tension between delivering fast and high quality/bug free and what is necessary for medical software or financial calculations might not be necessary for games.

The question of whether to write tests at all is not really about TDD though.

Iterate on the design til the snapshots look the way the design team wants.

That's just an extended red where you get feedback from elsewhere.

Um, show the snapshot to a designer? When it feels right, lock in the snapshot ("green") and then move on to refactor.

Or, probably more likely a group of snapshots.

snapshot test driven development again. i already wrote a similar answer in response to your other comment.

it follows the definition of TDD and it works really well (with some caveats) but again some people get hung up on what their impression of TDD is (e.g. unit tests checking to see if a car object has a steering wheel or whatever...) rather than what it actually is and what about it is that actually works.