4 ms·

Really? The Pixel 8, my first Pixel, shipped without working USB webcam support, which was one of the advertised launch features. To actually get that feature y

Really? The Pixel 8, my first Pixel, shipped without working USB webcam support, which was one of the advertised launch features. To actually get that feature you had to switch to the beta release track, which of course broke lots of the other things on the phone. Notable things that have been broken for a month or more on the beta track since I owned a Pixel 8 include tap to pay and the unlock screen.

PUSH_AX 2y ago
We could do anecdotes all day. Unless there is hard data on how brittle or robust these devices are it all seems a bit pointless.
- ibash 2y ago
  No, anecdotes are data. You can't just ignore customers and claim their experience isn't hard data. One of my pet peeves is engineers making excuses for incompetence.
  - mardef 2y ago
    Ok, so my Pixel 1, 3, 5, and 7 have had no problems. Data shows 100% reliability then?
  - izacus 2y ago
    So the fact that my iPhones wifi failed means that they're all terrible products and we shouldn't look at engineering practices like failure rate statistics? Or do we just do that for brands we're not fanboys of like __true__ engineers?
  - PUSH_AX 2y ago
    Good luck with that. Sure it's data, it's the worst possible data you could choose to make an informed decision. If you want to gain insight by selectively reported, highly biased reports of a tiny sample size, go for it.
  - glenstein 2y ago
    >No, anecdotes are data They're not good data, they're some of the worst. Your idiosyncratic one-off experience should be addressed, but not necessarily generalized from. I feel like this is an important, perhaps even the most fundamental prerequisite for information literacy.
  - tick_tock_tick 2y ago
    I agree they are 100% data that's why we can say with absolute confidence there are no issues. (source my anecdotes)
  - zoeysmithe 2y ago
    tbf this is abusing the word anecdote a bit. Anecdotes are unreliable narratives and hearsay, not facts or data. An anecdote is "I forgot to pray before bed last night and now I have a headache. See God is punishing me." and other people agreeing with this happening to them. Saying, "here is a documented pixel bug that was released on day x but wasn't fixed until day y" is evidence and data. Once its documented as a real bug then its no longer in the land of weird anecdotes. How you categorize that is up to you. You can be dismissive of what that bug broke as an "unimportant feature" but its no longer an anecdote.
- oxide 2y ago
  anecdotal evidence is what I usually base my purchases on, which is why I've never bought a Google device after being burned (literally) by the Nexus 6P battery issues. you can pretend it doesn't matter, but bad word of mouth is all it takes for me.
  - digging 2y ago
    > but bad word of mouth is all it takes for me. That's fine, but it's also entirely different from saying that the phones are objectively unstable and bad for everyday use.
  - Gigablah 2y ago
    I have been burned twice by iPhone battery issues (specifically my iPhone X). Battery started discharging rapidly, I got it replaced, barely a year later it’s dying again.
    - hello_moto 2y ago
      This is me + wife with Pixel 3 despite "Battery Saving" mode and killall apps. The screen is eating up the battery like me drinking water on a hot California weather.
- lordnacho 2y ago
  But who is going to have the data that we need to assess this? The firm that has an interest in everyone thinking there's no data, and that we should withhold judgement. There's not a lot of good choices here, either you assume that because there's no info, everything is fine, or you assume that the one guy complaining is one of many.
- webnrrd2k 2y ago
  A quick search turns up problems, enough so that, as a consumer, I'd be concerned. Is that hard enough data to reach a conclusion in a major scientific journal? No. Is it enough data so that, as a consumer looking to purchase one, I would be concerned? Probably. Is it enough data that I'd expect some engineer at Google (or wherever) to pay attention and address? Certainly, I would expect some engineering team to pay attention to public forums and address issues as they arise. It doesn't seem to be happening. If these phones are supposed to be a flagship items, and I think it's reasonable to claim that they are, it's also reasonable to expect flagship support.
seattle_spring 2y ago
I'm sure we could also find anecdotes of some iPhone users having features necessary for them blocked or non-functional. It does not mean that the vast majority of people cannot still use the device without incident as a "daily driver."
- jeffbee 2y ago
  I used an iPhone from launch to the iPhone SE3 and I can't recall there ever being a feature printed on the box or hyped by Steve Jobs on stage that did not work out of the box, or that later stopped working.
  - glenstein 2y ago
    Here's one about battery life: https://discussions.apple.com/thread/255046014?sortBy=rank https://discussions.apple.com/thread/255046014?sortBy=rank
  - SideQuark 2y ago
    You must have had that single magic version of Apple Maps no one else got for a long time on release. They lost the batterygate lawsuits, right? Guess you missed that fiasco that resulted in Apple paying out over half a billion. In this case Apple deliberately degraded previous user experiences on older phones, which means previous behavior (in this case performance) stopped working, done deliberately by Apple. yes, it didn't go to zero, but it didn't do what it once did as decided remotely by Apple). Apple also promised user data security, sold user data, and got hauled before Congress in 2011 for that. But I guess your user data was safe in offshore data silos. I could go on, but I think your recall on iPhone downsides stopped working.
    - kaba0 2y ago
      > They lost the batterygate lawsuits, right? Guess you missed that fiasco that resulted in Apple paying out over half a billion. In this case Apple deliberately degraded previous user experiences on older phones, which means previous behavior (in this case performance) stopped working, done deliberately by Apple Let’s not share this absolute misinterpretation of what happened. Apple fcked up big time on communication, that’s for sure, but it was an absolutely well meaning feature for an old device, lengthening their lifespan. They saw a bunch of random poweroffs due to degrading batteries not being able to output enough power to the CPU, and pushed an update that decreased the CPU clock down a bit. This of course degraded performance, and not having informed the buyers, making it a choice, they lost a lawsuit. But if they would actually do the communication well, it could have been an excellent positive PR, them fixing a bug for a 4 or so years device!
refulgentis 2y ago
So you think there should be more testing so the testing track is stable? I worked on Pixel, left Google in October. I agree vehemently with what you're saying, its just, you're barking up the wrong tree on a couple different levels, the easy one above, and a more difficult one below. Management did what you wanted a few years back, #1 and #2 and #3 priorities were "stability above all else" since Pixel 6. This unfortunately didn't do anything in practice, other than enable newly minted middle managers to punch down, hoard work[1], and hide poor decision making and lying easily.[2] Net negative effect on product of course. What managers wanted to legislate was "care about your features", but I observed over years that you simply can't enforce that. Ironically, given the above behavior from the new management layer, people got more detached. Unit test coverage went up, I'd bet, which is also a lesson in unit tests have significantly diminishing returns. E2E tests are hard and flaky, but they pay 100x dividends in these situations. What you want to legislate is the truffle hunting that lowest level management does is bad. i.e. say we can definitely do whatever pet thing some guy 3 levels up says we need to copy from iOS this year. Then, hold it back because it's not done, but still announce it. Then, layer on a special process to get you on the betas to get the feature you thought you were buying. All of this keeps each individual happy and yet, remarkably, leads us directly back to the initial situation we were trying to fix. From all this, you can also derive why things only launch, and never improve (tl;dr: management has 0 incentive to do anything other than latch onto the latest vague ask / iOS copying from above) [1] Estimate everything takes 3-5x engineers it did 3 years ago. it's a huge win: I'm managing this team because I did it myself 3 years ago, so this makes clear what a talented engineer I was/am. When I solely listen to the vague asks from people 3 steps above, they'll want to give me the headcount I need to get their pet project done, so this gives me more reports. My compensation scales with report count. And if the estimate is questioned in any depth, well, we're making sure we have enough to deliver this Priority™ at high Quality™. Also, no one is going to question it anyway, my manager made me a manager because they trust me. [2] it's very easy to work around blatant irresponsibility by flipping it into "the guy lower on the totem pole is insufficiently committed to quality and collaboration [taking forever to do anything]"
- jeffbee 2y ago
  Yes, I think the dogfood stage before the beta release should be more thorough. For the record, I was also adamant about this while I still worked at Google. Google, especially Android, is way too eager to release to beta. You should not release to beta until you have stopped generating new defect reports in dogfood. If you do, you just annoy the beta testers and get a huge number of duplicate reports. That is exactly what happened this year with the lockscreen bug. If anyone in dogfood had even touched the phone once the problem and its severity would have been obvious. And breaking Wallet generated 13000 duplicate reports, breaking a core use case for beta users.

PUSH_AX 2y ago

We could do anecdotes all day. Unless there is hard data on how brittle or robust these devices are it all seems a bit pointless.

ibash 2y ago
No, anecdotes are data. You can't just ignore customers and claim their experience isn't hard data. One of my pet peeves is engineers making excuses for incompetence.
- mardef 2y ago
  Ok, so my Pixel 1, 3, 5, and 7 have had no problems. Data shows 100% reliability then?
- izacus 2y ago
  So the fact that my iPhones wifi failed means that they're all terrible products and we shouldn't look at engineering practices like failure rate statistics? Or do we just do that for brands we're not fanboys of like __true__ engineers?
- PUSH_AX 2y ago
  Good luck with that. Sure it's data, it's the worst possible data you could choose to make an informed decision. If you want to gain insight by selectively reported, highly biased reports of a tiny sample size, go for it.
- glenstein 2y ago
  >No, anecdotes are data They're not good data, they're some of the worst. Your idiosyncratic one-off experience should be addressed, but not necessarily generalized from. I feel like this is an important, perhaps even the most fundamental prerequisite for information literacy.
- tick_tock_tick 2y ago
  I agree they are 100% data that's why we can say with absolute confidence there are no issues. (source my anecdotes)
- zoeysmithe 2y ago
  tbf this is abusing the word anecdote a bit. Anecdotes are unreliable narratives and hearsay, not facts or data. An anecdote is "I forgot to pray before bed last night and now I have a headache. See God is punishing me." and other people agreeing with this happening to them. Saying, "here is a documented pixel bug that was released on day x but wasn't fixed until day y" is evidence and data. Once its documented as a real bug then its no longer in the land of weird anecdotes. How you categorize that is up to you. You can be dismissive of what that bug broke as an "unimportant feature" but its no longer an anecdote.
oxide 2y ago
anecdotal evidence is what I usually base my purchases on, which is why I've never bought a Google device after being burned (literally) by the Nexus 6P battery issues. you can pretend it doesn't matter, but bad word of mouth is all it takes for me.
- digging 2y ago
  > but bad word of mouth is all it takes for me. That's fine, but it's also entirely different from saying that the phones are objectively unstable and bad for everyday use.
- Gigablah 2y ago
  I have been burned twice by iPhone battery issues (specifically my iPhone X). Battery started discharging rapidly, I got it replaced, barely a year later it’s dying again.
  - hello_moto 2y ago
    This is me + wife with Pixel 3 despite "Battery Saving" mode and killall apps. The screen is eating up the battery like me drinking water on a hot California weather.
lordnacho 2y ago
But who is going to have the data that we need to assess this? The firm that has an interest in everyone thinking there's no data, and that we should withhold judgement. There's not a lot of good choices here, either you assume that because there's no info, everything is fine, or you assume that the one guy complaining is one of many.
webnrrd2k 2y ago
A quick search turns up problems, enough so that, as a consumer, I'd be concerned. Is that hard enough data to reach a conclusion in a major scientific journal? No. Is it enough data so that, as a consumer looking to purchase one, I would be concerned? Probably. Is it enough data that I'd expect some engineer at Google (or wherever) to pay attention and address? Certainly, I would expect some engineering team to pay attention to public forums and address issues as they arise. It doesn't seem to be happening. If these phones are supposed to be a flagship items, and I think it's reasonable to claim that they are, it's also reasonable to expect flagship support.

seattle_spring 2y ago

I'm sure we could also find anecdotes of some iPhone users having features necessary for them blocked or non-functional. It does not mean that the vast majority of people cannot still use the device without incident as a "daily driver."

jeffbee 2y ago
I used an iPhone from launch to the iPhone SE3 and I can't recall there ever being a feature printed on the box or hyped by Steve Jobs on stage that did not work out of the box, or that later stopped working.
- glenstein 2y ago
  Here's one about battery life: https://discussions.apple.com/thread/255046014?sortBy=rank https://discussions.apple.com/thread/255046014?sortBy=rank
- SideQuark 2y ago
  You must have had that single magic version of Apple Maps no one else got for a long time on release. They lost the batterygate lawsuits, right? Guess you missed that fiasco that resulted in Apple paying out over half a billion. In this case Apple deliberately degraded previous user experiences on older phones, which means previous behavior (in this case performance) stopped working, done deliberately by Apple. yes, it didn't go to zero, but it didn't do what it once did as decided remotely by Apple). Apple also promised user data security, sold user data, and got hauled before Congress in 2011 for that. But I guess your user data was safe in offshore data silos. I could go on, but I think your recall on iPhone downsides stopped working.
  - kaba0 2y ago
    > They lost the batterygate lawsuits, right? Guess you missed that fiasco that resulted in Apple paying out over half a billion. In this case Apple deliberately degraded previous user experiences on older phones, which means previous behavior (in this case performance) stopped working, done deliberately by Apple Let’s not share this absolute misinterpretation of what happened. Apple fcked up big time on communication, that’s for sure, but it was an absolutely well meaning feature for an old device, lengthening their lifespan. They saw a bunch of random poweroffs due to degrading batteries not being able to output enough power to the CPU, and pushed an update that decreased the CPU clock down a bit. This of course degraded performance, and not having informed the buyers, making it a choice, they lost a lawsuit. But if they would actually do the communication well, it could have been an excellent positive PR, them fixing a bug for a 4 or so years device!

refulgentis 2y ago

So you think there should be more testing so the testing track is stable? I worked on Pixel, left Google in October. I agree vehemently with what you're saying, its just, you're barking up the wrong tree on a couple different levels, the easy one above, and a more difficult one below. Management did what you wanted a few years back, #1 and #2 and #3 priorities were "stability above all else" since Pixel 6. This unfortunately didn't do anything in practice, other than enable newly minted middle managers to punch down, hoard work[1], and hide poor decision making and lying easily.[2] Net negative effect on product of course. What managers wanted to legislate was "care about your features", but I observed over years that you simply can't enforce that. Ironically, given the above behavior from the new management layer, people got more detached. Unit test coverage went up, I'd bet, which is also a lesson in unit tests have significantly diminishing returns. E2E tests are hard and flaky, but they pay 100x dividends in these situations. What you want to legislate is the truffle hunting that lowest level management does is bad. i.e. say we can definitely do whatever pet thing some guy 3 levels up says we need to copy from iOS this year. Then, hold it back because it's not done, but still announce it. Then, layer on a special process to get you on the betas to get the feature you thought you were buying. All of this keeps each individual happy and yet, remarkably, leads us directly back to the initial situation we were trying to fix. From all this, you can also derive why things only launch, and never improve (tl;dr: management has 0 incentive to do anything other than latch onto the latest vague ask / iOS copying from above) [1] Estimate everything takes 3-5x engineers it did 3 years ago. it's a huge win: I'm managing this team because I did it myself 3 years ago, so this makes clear what a talented engineer I was/am. When I solely listen to the vague asks from people 3 steps above, they'll want to give me the headcount I need to get their pet project done, so this gives me more reports. My compensation scales with report count. And if the estimate is questioned in any depth, well, we're making sure we have enough to deliver this Priority™ at high Quality™. Also, no one is going to question it anyway, my manager made me a manager because they trust me. [2] it's very easy to work around blatant irresponsibility by flipping it into "the guy lower on the totem pole is insufficiently committed to quality and collaboration [taking forever to do anything]"

jeffbee 2y ago
Yes, I think the dogfood stage before the beta release should be more thorough. For the record, I was also adamant about this while I still worked at Google. Google, especially Android, is way too eager to release to beta. You should not release to beta until you have stopped generating new defect reports in dogfood. If you do, you just annoy the beta testers and get a huge number of duplicate reports. That is exactly what happened this year with the lockscreen bug. If anyone in dogfood had even touched the phone once the problem and its severity would have been obvious. And breaking Wallet generated 13000 duplicate reports, breaking a core use case for beta users.