4 ms·

Yeah he's lamenting how poorly the external developers are being treated but seems like they are largely being treated the same as Apple treats its own employee

Yeah he's lamenting how poorly the external developers are being treated but seems like they are largely being treated the same as Apple treats its own employees

JKCalhoun 3y ago
I found it sometimes frustrating as well. But my experience was that it depended on the engineer/team/screener the Radar went to. Obviously if it was a bug I found, I much preferred to talk to the engineer in person who maintained the code in question. There were plenty of teams that were very good about jumping on bug reports and getting right back to me. In fact, a decade or so ago at Apple this was more or less the rule. My sense though is that engineering became overwhelmed with bugs especially as Apple itself became as successful as it has become. "In the old days" a smaller team would have one of the engineers on the team screen Radars — maybe rotating to a new engineer every week or so. Engineers could quickly mark a bug as a duplicate of another (recognizing a familiar backtrace or symptoms) or might be able to guess at a diagnosis and send it straight to the engineer in charge of the (likely) relevant code. A few teams I worked on were very good about daily "BRB"s (bug review board meetings). With a number of engineers in attendance, again, bugs were quickly dispatched to the right component, assigned to right engineer. Again though, as Apple grew, I saw bug screeners on many teams more or less automatically flipping Radars back to the Originator if there was not a litany of documentation attached to the Radar. What build of the OS, what hardware, a full sample, system diagnosis.... It was frustrating when it was an obvious bug — maybe even a UI bug — that would take someone all of 30 seconds to repro. I somewhat sympathize though as traffic no doubt began to become a firehose of bug reports. It seemed backwards to me though to put such a burden on the person who is simply trying to report the bug, trying to help you improve the software. Often in screening Radars the description alone was enough for me to know exactly where in the code the problem was. I didn't mind my time being spent at least scanning the Radar title and description. If it was not clear to me at that point, sure, flip it back for more info. The seeming rise of "auto-reject" is what began to irk me.
- MichaelZuo 3y ago
  What would the ideal structure look like in your opinion?
  - JKCalhoun 3y ago
    Ideally, daily BRBs (kept to an hour) with engineers attending. If it turns out there are too many Radars to keep the BRBs to an hour then there are issues elsewhere. At the same time, I didn't mention it above, engineers need to be allowed time in the product schedule to fix these bugs. As probably everyone knows, when a bug is kicked down the road once (because of scheduling constraints: hey, we gotta ship the software at some point!) it becomes easier still to kick it down the road when the next release dat rolls around (we lived with the bug this long...). I think engineers and users alike would love to see more bug--only releases of MacOS and iOS. People still talk about how wonderful SnowLeopard was simply because it was a bug-fix only (mostly?) release.
    - ryandrake 3y ago
      Incentivize screening Radars (and fixing them). There's no engineering glory in keeping your unscreened count at zero... nobody gets promoted for it.
      - JKCalhoun 3y ago
        Good point.
      - jbverschoor 3y ago
        Not everybody wants to get promoted
    - inferiorhuman 3y ago
      I think engineers and users alike would love to see more bug--only releases of MacOS and iOS. People still talk about how wonderful Snow Leopard was simply because it was a bug-fix only (mostly?) release. Apple's dot zero OSX releases have always been pretty bad, so yes Snow Leopard and the last iteration of Tiger look great by comparison. As an outsider I don't have fond memories of filing bugs with Apple in that era. The general opacity combined with corporate disinterest discouraged me to the point where it's been years since I've even thought about filing a bug. I dread new iOS releases. Sure there are usually unwanted changes (e.g. text selection in iOS 13), but the bugs... iOS 16 completely trashed whatever database Siri uses to map text to speech, so using Siri to play a song is usually a miss. Most recently it's decided the name Ben is really the name "Mouse Face". That's left a fair bit of egg on my face as I interact with those two people in two very different contexts. Sure, I could file a bug, but it's just easier to stop using Siri (which was never great in the first place). With Tiger I was trying to integrate LDAP (AD masquerading as OpenDirectory), and it turned out that OSX would just assign GID 0 to any LDAP backed user. To me that seems pretty fucking straightforward, obviously pretty severe. That bug report went nowhere (not even an acknowledgement) and if memory serves Leopard went out with the same issue. I also had a polycarbonate MacBook for personal use around the same time. I ended up filling out the RAM slots and discovered that after a certain amount of uptime that playing DVDs would eventually cause a kernel panic. That bug report actually did get a response, but only one. I think the computer itself died before that got fixed. As someone who went on to dick around with CalDAV and CardDAV, there were plenty of issues to be filed but it was never really worth the effort. But as with everything else, as bad as Apple is they're usually better than the competition. That's how I ended up replacing my recently deceased Intel MBP with a new ARM one. So long as market share holds I don't think Apple's got much incentive to reform. Although given that Tim Apple seems hell bent on pulling a Gil Amelio (my new MacBook SuperproairMax 15.323456" with the all new M-Centris really truly pro max upper bound superlative CPU sure looks great on the shelf) who knows how much longer that'll hold.
musicale 3y ago
Sad but probably true. I imagine Apple can afford to do better and it would pay off both internally and externally.

Yeah he's lamenting how poorly the external developers are being treated but seems like they are largely being treated the same as Apple treats its own employees

JKCalhoun 3y ago

I found it sometimes frustrating as well. But my experience was that it depended on the engineer/team/screener the Radar went to. Obviously if it was a bug I found, I much preferred to talk to the engineer in person who maintained the code in question. There were plenty of teams that were very good about jumping on bug reports and getting right back to me. In fact, a decade or so ago at Apple this was more or less the rule. My sense though is that engineering became overwhelmed with bugs especially as Apple itself became as successful as it has become. "In the old days" a smaller team would have one of the engineers on the team screen Radars — maybe rotating to a new engineer every week or so. Engineers could quickly mark a bug as a duplicate of another (recognizing a familiar backtrace or symptoms) or might be able to guess at a diagnosis and send it straight to the engineer in charge of the (likely) relevant code. A few teams I worked on were very good about daily "BRB"s (bug review board meetings). With a number of engineers in attendance, again, bugs were quickly dispatched to the right component, assigned to right engineer. Again though, as Apple grew, I saw bug screeners on many teams more or less automatically flipping Radars back to the Originator if there was not a litany of documentation attached to the Radar. What build of the OS, what hardware, a full sample, system diagnosis.... It was frustrating when it was an obvious bug — maybe even a UI bug — that would take someone all of 30 seconds to repro. I somewhat sympathize though as traffic no doubt began to become a firehose of bug reports. It seemed backwards to me though to put such a burden on the person who is simply trying to report the bug, trying to help you improve the software. Often in screening Radars the description alone was enough for me to know exactly where in the code the problem was. I didn't mind my time being spent at least scanning the Radar title and description. If it was not clear to me at that point, sure, flip it back for more info. The seeming rise of "auto-reject" is what began to irk me.

MichaelZuo 3y ago
What would the ideal structure look like in your opinion?
- JKCalhoun 3y ago
  Ideally, daily BRBs (kept to an hour) with engineers attending. If it turns out there are too many Radars to keep the BRBs to an hour then there are issues elsewhere. At the same time, I didn't mention it above, engineers need to be allowed time in the product schedule to fix these bugs. As probably everyone knows, when a bug is kicked down the road once (because of scheduling constraints: hey, we gotta ship the software at some point!) it becomes easier still to kick it down the road when the next release dat rolls around (we lived with the bug this long...). I think engineers and users alike would love to see more bug--only releases of MacOS and iOS. People still talk about how wonderful SnowLeopard was simply because it was a bug-fix only (mostly?) release.
  - ryandrake 3y ago
    Incentivize screening Radars (and fixing them). There's no engineering glory in keeping your unscreened count at zero... nobody gets promoted for it.
    - JKCalhoun 3y ago
      Good point.
    - jbverschoor 3y ago
      Not everybody wants to get promoted
  - inferiorhuman 3y ago
    I think engineers and users alike would love to see more bug--only releases of MacOS and iOS. People still talk about how wonderful Snow Leopard was simply because it was a bug-fix only (mostly?) release. Apple's dot zero OSX releases have always been pretty bad, so yes Snow Leopard and the last iteration of Tiger look great by comparison. As an outsider I don't have fond memories of filing bugs with Apple in that era. The general opacity combined with corporate disinterest discouraged me to the point where it's been years since I've even thought about filing a bug. I dread new iOS releases. Sure there are usually unwanted changes (e.g. text selection in iOS 13), but the bugs... iOS 16 completely trashed whatever database Siri uses to map text to speech, so using Siri to play a song is usually a miss. Most recently it's decided the name Ben is really the name "Mouse Face". That's left a fair bit of egg on my face as I interact with those two people in two very different contexts. Sure, I could file a bug, but it's just easier to stop using Siri (which was never great in the first place). With Tiger I was trying to integrate LDAP (AD masquerading as OpenDirectory), and it turned out that OSX would just assign GID 0 to any LDAP backed user. To me that seems pretty fucking straightforward, obviously pretty severe. That bug report went nowhere (not even an acknowledgement) and if memory serves Leopard went out with the same issue. I also had a polycarbonate MacBook for personal use around the same time. I ended up filling out the RAM slots and discovered that after a certain amount of uptime that playing DVDs would eventually cause a kernel panic. That bug report actually did get a response, but only one. I think the computer itself died before that got fixed. As someone who went on to dick around with CalDAV and CardDAV, there were plenty of issues to be filed but it was never really worth the effort. But as with everything else, as bad as Apple is they're usually better than the competition. That's how I ended up replacing my recently deceased Intel MBP with a new ARM one. So long as market share holds I don't think Apple's got much incentive to reform. Although given that Tim Apple seems hell bent on pulling a Gil Amelio (my new MacBook SuperproairMax 15.323456" with the all new M-Centris really truly pro max upper bound superlative CPU sure looks great on the shelf) who knows how much longer that'll hold.

musicale 3y ago

Sad but probably true. I imagine Apple can afford to do better and it would pay off both internally and externally.