October 1, 2025 at 12:00 am
Comments posted to this topic are about the item PRs Are Like Trouble Tickets
October 1, 2025 at 6:33 am
There is a conflict between people doing the reviews and people requiring the reviews. They interrupt the flow.
I would prefer a PR that is small and focused, but that requires people who are prepared to do a lot of PRs. The scarcity of reviewers means that I have to submit PRs that are bigger and broader, which take longer to review.
There is the question of what we want PRs to cover. Linting, formatting, testing, code quality, and security scanning should be part of the CI/CD workflow and also available on our workstations. That way, you are not doing a PR on basic code hygiene; you are doing a PR on the important stuff.
I've found that Co-Pilot makes useful observations on a PR.
I describe the intent and decisions for my PR using markdown. My team find this approach valuable as it gives them the context for the PR. A little bit of time upfront greases the wheels for them and, in doing so, makes reviewing a PR less onerous.
I am beginning to understand the viewpoint of pair programming aficionados. It isn't two people doing the work of one. It's a real-time PR that is a preventative rather than a retrospective, and prevention is better than a cure, even when that cure isn't refused as "risk-accepted".
October 1, 2025 at 8:52 am
When you need to change an old procedure for the first time and decide to format it or make some other cosmetic changes, to this stuff first and check it in.
Particularly formating tends to produce tons of changed lines and it is hard to find the real code changes in the lot of formating stuff.
God is real, unless declared integer.
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply