> Pull Requests aren’t the best tool for everything A lot of teams I've worked with have had trouble with the listed problems. They're a sign that your team do

> Pull Requests aren’t the best tool for everything A lot of teams I've worked with have had trouble with the listed problems. They're a sign that your team doesn't understand or hasn't defined the purpose of a code-review and how to conduct them. It's also indicative, if you have comments on architectural decisions in PRs, that you have broader communication issues within your organization. Another drawback of PRs: don't make it personal. A lot of folks have a hard time with this. A shared code-base doesn't belong to any one individual. So don't say things like, "You should do this," or ask, "Why did you choose to do it that way?" A constructive suggestion is about the code and is given in the direct, imperative tense: "If this function used a higher-order function parameter here it would map over the results and remove these two intermediate bound variables and make this function more general." You're not talking about the person or asking them to justify themselves. You're collaborating on the code. Offer constructive suggestions on improving the code. Keep in mind the style guide and the other suggestions by the OP.