I’m pretty sure I’ll be getting one, but then again I’m an iOS developer and will likely be playing around with developing apps for it.

I can definitely see myself using this in the (home) office and around the house. Purely for productivity this looks like it’ll be amazing

Yeah it’s probably one of our more hotly discussed issues at eng. catch-ups. A few newer starters come from more startup backgrounds and find it super frustrating.

Pros & cons as with any process 🤷

This is cute af. I love it

Ours is pretty intense - large bank, 60 or so iOS engineers actively contributing to a mono-repo:

1. We have about 15 CI steps that pick up on anything from basic linting to security concerns (SonarQube). Unit tests, UI tests, etc.
2. We have a template that PR authors follow to add descriptions, test plans, devices tested on.
3. Reviewers are automatically assigned using a round robin system
4. Reviewers obviously review the code, but also execute the test plan, which includes accessibility testing.
5. All PRs require 2 approvals.
6. A bunch of other stuff (uploading artefacts, generating gRPC protos) that probably isn’t worth going into detail.

It’s intense, and PRs on average take a week or so to get merged. In saying that, it is the highest quality and most well-architected codebase I have ever worked on.

If I were in your situation I’d push for the following:

• all PRs have one approval, preferably two depending on team size
• code is tested by someone else before being merged to main
• use linters, Danger, etc to pick up on trivial shit
• a few manual checks like ensuring code is unit tested
• a Github PR Reviewer guide describing common issues to look for, tone of messaging when leaving comments (“be nice”, “make it clear when you are adding optional nit-picks”, etc)
• encourage authors to add review comments to their own PRs for any bit of code that isn’t immediately obvious
• stretch goal: look into generating code coverage reports on your PRs, add quality gates