4 ms·

I sympathize: even filing radars internally at Apple gets much of the same treatment, albeit with the ability to see the state of the radar.

changoplatanero 3y ago
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.
jbverschoor 3y ago
Which basically mean they’re understaffed with people who enjoy fixing bugs. Fixing bugs, fine tuning, just gardening the code base
- dewey 3y ago
  Or it's too annoying to triage, find (If app store search is anything to judge by) and replicate bugs because the tooling is too annoying or not collecting the right information if people submit bugs. If that's the case then even if you would in theory have the resources to work on bugs it will not be very efficient.
- ladberg 3y ago
  I think a lot of Apple engineers would love to have more time to be able to fix bugs but for the most part they're all stretched pretty thin. Prioritizing fixing old bugs over developing new features isn't a call an IC can really make so I'd kinda argue that the issue is either "overstaffed with designers+execs who spend engineer time on UI changes" or "understaffed with engineers in general" and not an issue with the mindset of the current engineers.

changoplatanero 3y ago

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.

jbverschoor 3y ago

Which basically mean they’re understaffed with people who enjoy fixing bugs. Fixing bugs, fine tuning, just gardening the code base

dewey 3y ago
Or it's too annoying to triage, find (If app store search is anything to judge by) and replicate bugs because the tooling is too annoying or not collecting the right information if people submit bugs. If that's the case then even if you would in theory have the resources to work on bugs it will not be very efficient.
ladberg 3y ago
I think a lot of Apple engineers would love to have more time to be able to fix bugs but for the most part they're all stretched pretty thin. Prioritizing fixing old bugs over developing new features isn't a call an IC can really make so I'd kinda argue that the issue is either "overstaffed with designers+execs who spend engineer time on UI changes" or "understaffed with engineers in general" and not an issue with the mindset of the current engineers.