4 ms·

It looks like OP is mad that they have to spend 2 DAYS a month running down permissions or overrides due to broken dependencies. I mean they are supposed to do

It looks like OP is mad that they have to spend 2 DAYS a month running down permissions or overrides due to broken dependencies. I mean they are supposed to do what else exactly? Just heads down keep writing code and nothing else? The question is if they are being overworked for this or if theyre mad that their cushy well paid perk filled 9-5 job is inconveniencing them twice a month to get out of their seat. Like what? The only times I’ve seen that work is when absolutely no one actually runs the code. If you want to write code at places where it touches billions of people (for better or worse), then this seems like a better way to do things than what other companies seem to do.

cphoover 5y ago
This doesn't really address the problems OP brought up... like centralized authority, rebuilding for rebuilding's sake, and priorities interrupted because of sporadically imposed deadlines from other teams... OP mentions a timeline for fixing another critical issue was delayed because of an immediate requirement for upgrading a dependency. I can see how that could be frustrating, especially if not communicated with due-notice ahead of sprint/agile planning. Just because OP is payed well doesn't mean they can't point out frustrations borne out of what they view as inefficient process.
- ramraj07 5y ago
  I’m not convinced that it’s inefficient though. Google is quite likely the company that’s running the most amount of code in the most amount of computers compared to ANY company in the planet, and their system works. I’ll be curious how Microsoft works especially with internal APIs because they’re kinda the one competitor in terms of mammoth code bases and are famous for keeping backwards compatibility for external interfaces at the least. Minimally they also use monorepos, so there’s that.
brigade 5y ago
I would be annoyed if 10% of my development time was consistently wasted because no one cares about building a foundation that doesn’t shift like quicksand.
- Jensson 5y ago
  Alternative is spending 50% of your time in meetings where you have to motivate what the code you write should look like in order to avoid people spending 10% of their time writing migration code. And it isn't like those with dependencies has no recourse, if they think one of the dependencies breaks too often they just remove the dependency and live without it. The library maintainers of course wants to avoid that so they have strong incentives to not break API's. And they can't break API's without first notifying or fixing their users either since then their code will just get rolled back, at Google it is typically much more work to break an API than for the downstream dependencies to fix those breakages.

cphoover 5y ago

This doesn't really address the problems OP brought up... like centralized authority, rebuilding for rebuilding's sake, and priorities interrupted because of sporadically imposed deadlines from other teams... OP mentions a timeline for fixing another critical issue was delayed because of an immediate requirement for upgrading a dependency. I can see how that could be frustrating, especially if not communicated with due-notice ahead of sprint/agile planning. Just because OP is payed well doesn't mean they can't point out frustrations borne out of what they view as inefficient process.

ramraj07 5y ago
I’m not convinced that it’s inefficient though. Google is quite likely the company that’s running the most amount of code in the most amount of computers compared to ANY company in the planet, and their system works. I’ll be curious how Microsoft works especially with internal APIs because they’re kinda the one competitor in terms of mammoth code bases and are famous for keeping backwards compatibility for external interfaces at the least. Minimally they also use monorepos, so there’s that.

brigade 5y ago

I would be annoyed if 10% of my development time was consistently wasted because no one cares about building a foundation that doesn’t shift like quicksand.

Jensson 5y ago
Alternative is spending 50% of your time in meetings where you have to motivate what the code you write should look like in order to avoid people spending 10% of their time writing migration code. And it isn't like those with dependencies has no recourse, if they think one of the dependencies breaks too often they just remove the dependency and live without it. The library maintainers of course wants to avoid that so they have strong incentives to not break API's. And they can't break API's without first notifying or fixing their users either since then their code will just get rolled back, at Google it is typically much more work to break an API than for the downstream dependencies to fix those breakages.