Pull Requests are NOT ONLY for Code Review
Many companies have a common strong problem — not enough documentation… or rather — not enough knowledge about the software they produce. I understand why it is happening, writing professional documentation consumes too much time and is even more boring task, that's two reasons to ignore writing professional documentation.
But there are some easier ways to write documentation
Let’s think, most developers don’t like writing official documents in official style, but they write many descriptions what they code is doing, not in official sources, but in private messages, emails, PR comments, and sometimes Jira comments (it’s rare but sometimes they do that).
Any documentation is much better than small or non-existent documentation, so copying descriptions “what is is doing” sounds like way to have excellent code coverage… with not excellent text quality, but it’s good enough.
That may help, I heard about this practice many times but I never saw it in practice… but there is something even easier!!!
Start using pull requests as tool for educating people what other people are doing.
It’s very easy, just change the required reviewers from 1 to 2 or 3. Sounds like more people will have to do the same job, but that’s not exactly true. When there will be more people that will read code, more people will have knowledge about this change in code. Remember, if 3 people know about something, it’s 50% more than 2 people.
But don’t set required numer to high, because then there will be some kind of “collective responsibility” and it will consume to much time. You don’t want to go from one extreme to another.
So as I written before, increase reviewers from 1 to 2 can give many positives in knowledge about what others are doing. In some cases 3 reviewers may be still good option, but probably it is the maximum.
But what about daily, weekly, status meetings etc?
These knowledge-exchange meetings sound good, but in most cases only sound. If developers don’t see code, they don’t exactly know what is changed and if topic isn’t close related to what they are doing, they may forgot about it immediately after meeting (or inside it).
Approving pull request = part responsibility for that code, so they will not even know exactly learn what is going to change, but they will also check it carefoully.
