3 ms·

Number of PR's means very little with overall productivity. It's a vanity metric.

Forge36 4y ago
100% I made 400 last year. It was two fixes across many files owned by many different teams. Ideally it would have been two. Sometimes playing the politics game is required.
- spullara 4y ago
  To be fair Twitter has a monorepo.
  - threeseed 4y ago
    Mostly. Many of their foundational components e.g. Finagle are open sourced and in separate repos. https://github.com/orgs/twitter/repositories https://github.com/orgs/twitter/repositories
    - OmarAssadi 4y ago
      I haven’t seen much info regarding their setup, aside from the bits about Pants and Bazel. Are those actually the upstream repositories, though? And is it known how they interact with them? Google has Copybara [1], which allows portions of a monorepo to live outside as an entirely separate repository without the need for things like Git submodules. It supports synchronization of histories, pull requests, path and file transformations, etc. In that sense, something like Copybara would allow them to, relatively, easily open source those bits, receive outside commits, and then sync the changes back to the monorepo. [1]: <https://github.com/google/copybara https://github.com/google/copybara>
  - super_linear 4y ago
    (and so does Tesla)
SkyPuncher 4y ago
It's only useful in debugging a bad situation. Larger PRs are associated with slower development velocity. However, it's not clear if that's because larger PR tend to come from inexperienced developers or experienced developers are making significantly more complex changes. Anecdata: It took me 4 weeks to write a 250 net new lines of code line PR. Normally, I'll write about 1k lines of code per week. I ended up having a tasks that significantly changed security models and required a lot of small, distributed changes.
- threeseed 4y ago
  > Larger PRs are associated with slower development velocity There are many reasons PRs can be large. Often it's indicative of broader issues e.g. lack of automated testing, inadequate CI/CD processes, incomplete business requirements etc.

100% I made 400 last year. It was two fixes across many files owned by many different teams. Ideally it would have been two. Sometimes playing the politics game is required.

spullara 4y ago
To be fair Twitter has a monorepo.
- threeseed 4y ago
  Mostly. Many of their foundational components e.g. Finagle are open sourced and in separate repos. https://github.com/orgs/twitter/repositories https://github.com/orgs/twitter/repositories
  - OmarAssadi 4y ago
    I haven’t seen much info regarding their setup, aside from the bits about Pants and Bazel. Are those actually the upstream repositories, though? And is it known how they interact with them? Google has Copybara [1], which allows portions of a monorepo to live outside as an entirely separate repository without the need for things like Git submodules. It supports synchronization of histories, pull requests, path and file transformations, etc. In that sense, something like Copybara would allow them to, relatively, easily open source those bits, receive outside commits, and then sync the changes back to the monorepo. [1]: <https://github.com/google/copybara https://github.com/google/copybara>
- super_linear 4y ago
  (and so does Tesla)

SkyPuncher 4y ago

It's only useful in debugging a bad situation. Larger PRs are associated with slower development velocity. However, it's not clear if that's because larger PR tend to come from inexperienced developers or experienced developers are making significantly more complex changes. Anecdata: It took me 4 weeks to write a 250 net new lines of code line PR. Normally, I'll write about 1k lines of code per week. I ended up having a tasks that significantly changed security models and required a lot of small, distributed changes.

threeseed 4y ago
> Larger PRs are associated with slower development velocity There are many reasons PRs can be large. Often it's indicative of broader issues e.g. lack of automated testing, inadequate CI/CD processes, incomplete business requirements etc.