Post B5U80LqWPW7RXETpfk by jneen@unstable.systems
 (DIR) More posts by jneen@unstable.systems
 (DIR) Post #B5U80J5eenRQzIXNLM by jneen@unstable.systems
       0 likes, 2 repeats
       
       half the point of programming-tool design is to reduce the need for hypervigilance on the user.if we're designing tools that require you to be *more* hypervigilant, legitimately what use are they?
       
 (DIR) Post #B5U80LqWPW7RXETpfk by jneen@unstable.systems
       0 likes, 0 repeats
       
       employers will likely say that you should be hypervigilant all the time, no matter whatbut hypervigilance, famously, destroys your mind and body.when employers act like it's expected, it is a very strong message that they do not care about their workers.
       
 (DIR) Post #B5U80MrybasQi2AVZw by jneen@unstable.systems
       0 likes, 0 repeats
       
       what *actually* happens is the workforce pretends to be hypervigilant all the time ("i always check the output!") in ways that are clearly, obviously impossible, and which if true would have turned them into an empty husk of a human being - just to say they "aren't vibe coding" (they are)
       
 (DIR) Post #B5U80NnPA4oXa92N5k by jneen@unstable.systems
       0 likes, 0 repeats
       
       As for automated testing / acceptance checks as a replacement, that mitigates the problem somewhat, but certainly doesn't eliminate it. The tool can make your tests pass, sure, but did it architect it correctly? How do you structurally evaluate that? You fall into the linter tar-pit pretty quickly with that approach.
       
 (DIR) Post #B5U80OrLCvYasdt1rk by jneen@unstable.systems
       0 likes, 0 repeats
       
       i think the idea that there is a quick, easy measure of "good code" that is universally applicable and not filled with holes is... well it's just not true, and we're not even close to defining the problem rigourously, let alone solving it.
       
 (DIR) Post #B5U80Pr1VatfxwkI0e by jneen@unstable.systems
       0 likes, 0 repeats
       
       we already had this discourse a decade ago over TDD, and the result was a pretty universal "automated tests are important and you should have them, but it doesn't mean you don't need QA"
       
 (DIR) Post #B5U80QkgAfPskYmjlA by jneen@unstable.systems
       0 likes, 0 repeats
       
       not to mention most of the devs i see in the field are generating their *tests* with AI, which completely defeats their purpose in catching AI errors.
       
 (DIR) Post #B5hjYBBam1c9g5oBCi by kirakira@furry.engineer
       0 likes, 0 repeats
       
       @jneen "ai can do unimportant menial tasks like write tests" being a relatively common sentiment makes me feel like nobody knows what tests are for
       
 (DIR) Post #B5hjYBO01tXUIZc5Xk by whitequark@social.treehouse.systems
       0 likes, 0 repeats
       
       @kirakira @jneen yesyesyesyes
       
 (DIR) Post #B5hjYBWrUwd0k3lAMC by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @whitequark @kirakira @jneen meanwhile design of good tests and test corpora is one of the biggest challenges facing libscopeprotocols in particular
       
 (DIR) Post #B5hjfRR4kvNk6QVtoW by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @whitequark @kirakira @jneen like say i want a test for the PCIe link layer, do i write a whole PCIe implementation to generate test packets? Distribute hundreds of MB of waveform captures just to enable tests? If it's real captured data rather than synthetic how do i know what the expected decoder output is?
       
 (DIR) Post #B5hjz2NBeFCeAD2Rw8 by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @whitequark @kirakira @jneen i have hundreds of decodes i want to write tests for but for complex protocols rather than "add these inputs" it's... Not easy
       
 (DIR) Post #B5htJ2HEc7Z9FFrhwW by brianstorms@mastodon.social
       0 likes, 1 repeats
       
       @jneen Tesla’s lack of QA care and attention forces hypervigilence on its drivers, given the frequent software updates where you never know what the new stupid, useless “features,” and fixes, if any, have done to the UI/UX and driving experience. You ignore the changes at your—and your passengers’—and other people’s—risk.My solution: wait weeks/months before accepting a software update. Of course, this only puts off the hypervigilence drama.
       
 (DIR) Post #B5htRBpkxwF5CYtuMa by trentshell@mastodon.social
       0 likes, 0 repeats
       
       @jneen do you use cruise control when driving?
       
 (DIR) Post #B5iZ8i9CnQRVzerwAq by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @whitequark @kirakira @jneen especially when you have to account for things like different code paths based on your GPU having or lacking a particular feature flag. And making sure the code actually checks those feature flags it depends on (failure to do so caused three bugs i found earlier today, one an easy fix the other two will be more work)
       
 (DIR) Post #B5jNV1NOymQhi5LCrI by beeoproblem@mastodon.gamedev.place
       0 likes, 0 repeats
       
       @azonenberg @whitequark @kirakira @jneen this whole sub-thread hits something that drives me up the wallsI swear half the articles I see talking about automated testing, unit testing etc treat it as if you could look at [complex thing] throw, say, 100 simple cases at it that hits some percentage of the code and have "complete" coverage. Only thing I can think is "either you put in zero effort toward real acceptance tests or you have coverage gaps big enough to fit a battleship"
       
 (DIR) Post #B5jZaOsiDMmvVWJkZ6 by AMS@infosec.exchange
       0 likes, 0 repeats
       
       @azonenberg @whitequark @kirakira @jneen I've done matlab/octave/python version of the datasheet test vectors put through a channel simulation FIR for stuff in the past. Not perfect but gives you something to test that will at least exercise the filters.