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.
620 karma · joined April 17, 2023
The search box is gone and you're supposed to ask Rufus now.
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.
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 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.
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.
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.
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.
* 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.
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.
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.
That's just an extended red where you get feedback from elsewhere.
Or, probably more likely a group of snapshots.
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.
set up a rendering profile and preconditions that generates a minimal snippet of images/video using a predefined GPU profile.
then test for either a pixel perfect reproduction of the correct behaviour or for the properties you're looking for (if it doesnt reproduce deterministically).
this is one way. i also subscribe to the view that if the type system is modified to become stricter in such a way that it can fail reliably in the presence of this type of bug that this is also good enough.
some people might argue that these arent "strictly" TDD by some definition but they set out a path to follow red green refactor and confer identical benefits so my view is who gives a duck?
I don't have enough domain expertise to know which variant of these approaches is best but I'm enough of a TDD expert to know that what you're implying isnt possible is actually something you would would probably derive a lot of value from if you did it.
You would have the same problem if you wrote tests like that after the code.
TDD has no opinion about the level at which you wrote your test, it just assumes it's the correct one.
This is the number one biggest misconception about TDD which I keep seeing repeated on hacker news.
The general idea of "readable specification language" was an inspired one but it failed on execution - it has gnarly syntax, no typing and bad abstractions.
This results in poor tests which are hard to maintain and diverge between being either too repetitive to be useful or too vague to be useful.
The ecosystem is big but it's built on crumbling foundations which is why when most people used it most of them got frustrated and gave up on it.
Annoyingly there's a certain amount of gaslighting around it too ("it didnt work for you coz you werent using it correctly") which is eleven different kinds of wrong.
An executable spec like gherkin or hitchstory is config - it has no loops or conditionals. There are a number of rarely recognized benefits to this.
Usually there either arent any in which case bugs get missed or there are 5 very cheap ones running mindless scripts who are standing in for the devs' inability or unwillingness to write decent automated tests but dont catch the really deep level thorny stuff.
Moreover, the best QAs would almost always try to be not QA - to shift into a better respected and better paid field.
I wish it werent so (hence my username) but there is a definite class divide between devs and QA and it shows up not just in terms of the pay packets but also who gets the boot in down times and who gets listened to. This definitely affects the quality of people.
I think it's overdue an overhaul much like the sysadmin->devops transition.
Nonetheless it looks like he was both willing and able to push back on a good deal of the AI stupidity raining down from above and then he was removed and then, well, this...
When I saw his interview: https://thenewstack.io/github-ceo-on-why-well-still-need-hum... i thought "oh, there is some semblance of sanity at Microsoft".
This was after seeing those ridiculous PRs where microsoft engineers patiently deconstructed AI slop PRs they were forced to deal with on the open source repos they maintained.
When he was gone a few months later and github was folded into microsoft's org chart the writing was firmly on the wall.
Bundling codex with uv isnt going to meaningfully affect the number of people using it. It doesnt increase the switching costs or anything.
Usually whole subtasks need to be junked and others created.