← Back to context

Comment by puffoflogic

5 years ago

It is interesting how much weight the author puts on bypassing process and bureaucracy to the success of the project.

Under regular circumstances, you can't just walk in and change another team's header files, nor force them to make a particular change you want to make happen, so normally, it would be very difficult to make changes affecting so many different projects.

  • It's also true that projects with strict rules about what each individual commit fixes can make it hard to fix a bunch of highly related bugs at once. Patch-based OSS projects can be like this too.

  • Is that an Apple thing? Because I've definitely worked on large-scale commercial projects where changes to everyone's includes were routine.

    • What I described is an Apple thing. I would not know practices at other companies. I'm sure there are other ways of organizing work.

      Then again, an OS and its associated apps are very large scale indeed, and have grown by necessity over a very long period of time, by a very heterogeneous team. Not sure if your large scale projects had similar concerns.

He admits else where on Quora to having Aspergers. It's been in my experience, and take that with a grain of salt, that those with Aspergers tend to resistant authority when they feel the authority is arbitrary, hurtful or incompetent. It's possible in the past, he was burned by the bureaucracy at Apple.

  • > that those with Aspergers tend to resistant authority when they feel the authority is arbitrary, hurtful or incompetent.

    This seems like neurotypical behavior to me. I'm not sure who wouldn't be resistant to authority in a situation like that.

I think it depends on a whole matter of things - like the bug priorities: If someone is not aware of the context of a "minor" bug they may lower the priority, that would be a reasonable response.

Alternatively if there's a team running up on a release they will have many restrictions on any changes going in, including feature work from their own team, let alone some random potentially behavior changing ones.

Many of the processes exist because time has told us bad things happen if they don't: even small projects now generally require a review for minor patches at this point, or require tests even if making tests is hard.

There have been a few times where I have spent longer (sometimes way longer) building the infrastructure to make a test and the test, for a change that took less than a day. In the long run that infrastructure was super useful, but at the time there's a lot of "uuggghh, whyyy". In this particular case it seems that day-to-day slip was considered sufficiently important that they might want to bypass such.

The view from here is that doing anything at big SV tech is way more politics than tech.