6 ms·

OMG the red tape at Apple is unbelievable, but this is the first time I've seen anyone mention it. On my first day at Microsoft, I checked in code. At Apple it

by w0mbat 5y ago

OMG the red tape at Apple is unbelievable, but this is the first time I've seen anyone mention it. On my first day at Microsoft, I checked in code. At Apple it took nearly two weeks to get granted separate access to the apps's sourcecode, secret OS version, secret Xcode version, secret new OS headers (for some reason this was a separate line item), upcoming hardware versions (which I never saw anyway). Once up and running as a senior engineer with tons of experience, I had no autonomy and wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.

P_I_Staker 5y ago
That actually sounds pretty par for the course in many big tech companies.
- w0mbat 5y ago
  Nah. I've worked at other FAANG companies and I'm afraid that none had anything close to the Apple level of red tape. I have barely scratched the surface of describing it.
ganbatekudasai 5y ago
> wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews. I mean... how else? If this is iOS for example, this potentially goes out to in the order of hundreds of millions, or even a billion or so, user devices. If you want the due diligence process not to apply for a comment, where do you draw the line? (Not withstanding that the comment may be wrong, or have an effect anyway. Yes, weird things happen at scale.) Even if there were a class of code changes that were deemed not to need review and a "bug database number", with every build on every lever of the multi level builds, changes often need to be removed, quickly. Because they cause bad bugs, or because they collided with other changes, or for any other reason. You want to be able to remove that change, however innocuous it may have seemed, in the quickest and most efficient way possible. Sometimes across multiple builds. Without upsetting hundreds of other engineers that have made changes as well. For that, "random commit without metadata" does not cut it. But nobody is going to be upset if you simply add your comment change or whatever reasonable cleanup change to another change in the same project, in order to not have to open a new bug just for cleanup for example. It will then be reviewed, and have its fate tied in case of problems, with the other code. When I worked at another FAANG, it was exactly like that as well.
passivate 5y ago
At the end of the day, you applied for the job at a company whose success is at-least partially based on the structure and rules that were instituted by those who came before you. It could be that they were put in for a very good reason. I'm all for re-evaluating rules and making modifications, but erring on the side of caution is probably a good idea as well. Just my 2c, not necessarily disagreeing with your opinion.
- Apocryphon 5y ago
  No one knows the degree of red tape or dysfunctions at Apple until they're actually in the company. The aura of secrecy masks what's going on.

by w0mbat 5y ago

P_I_Staker 5y ago

That actually sounds pretty par for the course in many big tech companies.

w0mbat 5y ago
Nah. I've worked at other FAANG companies and I'm afraid that none had anything close to the Apple level of red tape. I have barely scratched the surface of describing it.

ganbatekudasai 5y ago

> wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews. I mean... how else? If this is iOS for example, this potentially goes out to in the order of hundreds of millions, or even a billion or so, user devices. If you want the due diligence process not to apply for a comment, where do you draw the line? (Not withstanding that the comment may be wrong, or have an effect anyway. Yes, weird things happen at scale.) Even if there were a class of code changes that were deemed not to need review and a "bug database number", with every build on every lever of the multi level builds, changes often need to be removed, quickly. Because they cause bad bugs, or because they collided with other changes, or for any other reason. You want to be able to remove that change, however innocuous it may have seemed, in the quickest and most efficient way possible. Sometimes across multiple builds. Without upsetting hundreds of other engineers that have made changes as well. For that, "random commit without metadata" does not cut it. But nobody is going to be upset if you simply add your comment change or whatever reasonable cleanup change to another change in the same project, in order to not have to open a new bug just for cleanup for example. It will then be reviewed, and have its fate tied in case of problems, with the other code. When I worked at another FAANG, it was exactly like that as well.

passivate 5y ago

At the end of the day, you applied for the job at a company whose success is at-least partially based on the structure and rules that were instituted by those who came before you. It could be that they were put in for a very good reason. I'm all for re-evaluating rules and making modifications, but erring on the side of caution is probably a good idea as well. Just my 2c, not necessarily disagreeing with your opinion.

Apocryphon 5y ago
No one knows the degree of red tape or dysfunctions at Apple until they're actually in the company. The aura of secrecy masks what's going on.