> Now I find that I rely more and more on brands to decide which things I buy, because I simply cannot trust user reviews in most of the cases.
The other day I came across something interesting: two comments, for two different but related products (dynamos). One comment was in German, the other in Italian, but they both had the same non-sequitur in them.
Apparently scammers reuse comments across products (not surprising) and languages (more surprising).
I don't think I subvocalise, I read way faster than I can speak. There's certainly ideas flowing through my mind as I read, but not sounds. It feels like a mixture between words, thoughts and emotions, not a stream of (silently) spoken words.
I bought a book on speed reading because I was dissatisfied with my "slow" reading, only to discover that according to their tests I was way up there in both speed and comprehension :-D
I was shocked to learn from that book that many people subvocalise - it felt so foreign (and utterly cumbersome) to me. I hadn't even considered people did that.
Most of the book was about not subvocalising - which I don't think I do anyway, so I never read it to the end.
Indeed if I read to my kids I'm often simultaneously reading one sentence aloud, and reading 1...2 sentences ahead for myself so I get the voices right. So in effect I'm reading the entire text twice while speaking it once.
Subvocalizing is much faster than speaking. In general, subvocalizing refers to pronouncing the words in your head, which can be picked up by observing neural activity in the vocal chords.
Even if your vocal chords were doing the full range of motion (they are not), when speaking, you also have to open and close your mouth, move your tongue, take in breath and expel it etc. It's much more than simply some activity in your vocal chords.
You can opt out of recaptcha by just boycotting the website which uses it.
But of course by "opt out" you mean to remain a user of a service but not the parts you don't like. Whether you are entitled to do this or not is still up for debate.
> You can opt out of recaptcha by just boycotting the website which uses it.
Ah, I was waiting for somebody to make this argument, which I find somewhat disingenuous given how widespread reCaptcha's use is.
With sites I don't care about leaving them is exactly what I do - but there are sites I pay a lot of money to use, and can't really avoid using for business reasons, yet they still subject me to reCaptcha.
The path I've taken instead is to address this with the site owners. Most weren't really aware of how overreaching reCaptcha feels to some, and I've had good discussions. Of course nobody changed their site based on my complaint, but I like to think I raised awareness.
> But of course by "opt out" you mean to remain a user of a service but not the parts you don't like.
Specifically, a part of user verification. I'm still not sure why they feel they need to verify my humanity - they've got my credit card details and everything.
> Whether you are entitled to do this or not is still up for debate.
Let me ask the opposite question: is the owner of a website entitled to sell my privacy for their own (debatable) convenience?
This is totally disingenuous, especially in a thread comparing to Tesla.
With Tesla, I'm directly buying their product or not, and they do have competitors that I could choose from (not particularly great ones yet, I'll admit, but they do exist today and they're going to get there eventually).
With Google's ad tech and captcha, my data is being siphoned off to them by third parties. I'm looking at totally unrelated service X, and suddenly I'm faced with Google. The burden of boycott becomes much higher than in the Tesla case, which makes it reasonable to state that opt-out is "not [practically] possible".
The situations would be comparable if upon encountering a Google captcha I could choose to solve somebody else's captcha to access the same service.
> my data is being siphoned off to them by third parties.
they are not "third-party". If a site uses google's products (like analytics or recaptcha), then you could reasonably consider them partner sites to google.
Indeed, google is difficult to boycott - no one is diputing it. However, google obviously isn't very offensive to a large number of people, because there are very dedicated groups who dedicate time and energy into boycotting companies like nestle (which is _very_ difficult to boycott). May be a lot of laymen just don't think that their data is worth protecting (whether they are right or not remains to be seen).
> Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor.
Agile just means closing as many feedback feedback loops as you can as early as you can, and to preserve opportunities to course-correct for as long as you can.
All this to keep the destructive effects of surprises (which are sure to catch you) as low as possible.
This is good engineering practice, plain and simple.
> All that can be changed as well but at some point it gets complicated!
Not everything has to be changed, that's just a strawman.
But not every detail has to be nailed down at the beginning either.
The idea behind Agile is to reduce risk. If there is no risk of the bus system changing on you, there's no harm in fixing it right at the beginning.
But if there is a chance it might, you'd do well to have systems in place which enable you to react to changes with a minimum (though non-zero, of course) amount of pain.
> However, I still think waterfall is the only approach when trying to design a hardware product. Electronics require pretty specific requirements up front before you design and order boards, obviously mechanical tooling can be even more expensive.
I disagree, having taken part in agile embedded development.
Sure, it looked a bit different from pure-software, but the same underlying principle of short iterations applied. Our definition of "short" was a bit different, but still...
And yes, you may have some "very specific" requirements, but you may also have some "pretty loose" ones -- just like software.
> But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept
See, there you go.
The core idea behind Agile isn't to have sacrosanct two week sprints (or even to have sprints in the first place), it is to close as many feedback loops as you can as quickly as you can. Whatever that means in practice.
This has been good engineering practice for longer than software exists.
I read that the Mercury space project created their software in half-day "sprints". Back in the '60s, on punch-card machines (I guess).
Maybe I am wrong in my understanding, but for agile to work, observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint. For the hardware where the validation can be quite lengthy, this is feedback loop is much, much longer. Especially true when the project gets closer to start of mass production.
> observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint.
Quite quickly, yes.
The next sprint...maybe? Not necessarily.
Sure, you'll stick it in the backlog. But whether you'll start working on this improvement immediately is a separate matter. If that's the best course of action, sure, do it. But maybe you have more pressing matters, and the present implementation will do for now.
Or... it's not possible to attack it in the next sprint, because a new board needs to be spun, and that takes preparation. Then it'll be slated for the appropriate time, by necessity. That doesn't mean you forego an agile approach -- it just looks different, because the landscape is different.
> Especially true when the project gets closer to start of mass production.
Sure. Which is why being able to make, and find, and correct your mistakes early, when it's not so dramatic yet, is the goal of that whole Agile song and dance.
As you're intimately familiar of course, surprises in engineering are usually the bad kind, and the later they come, the worse they catch you. So, have as much feedback as you can, as early as you can (and with as much fidelity as you can).
Too bad, really. Loom seemed nice.