I'm undoubtedly a senior or something like that, and I agree with your choices. And that the items in the article seem shallow.
Regarding file size, I've seen people insist on hundreds of tiny files to satisfy their interpretation of the SRP - single responsibility principle - to the extent a codebase is more difficult to read because half of the files are almost entirely boilerplate, pointing to boilerplate in other files. It makes some people happy, but doesn't always make a better codebase to work with. (Though for some things like, say, Glibc, that approach to systematic file layout is quite helpful, even when some files have only one non-comment line.)
I've also found when I see someone talking about uncomfortably small or large files, it's a mistake to presume what they have in mind. For some people, a 500 line source file is an enormous monstrosity that should never have existed. For others, 2000 lines (in the same language as previous) is a single good day's work containing one medium-size algorithm.
I also agree with you about about PR sizes, because I hold the view that the optimal unit of review (ie PR that makes sense) is larger than the optimal size of a well-explained logical commit. Although, the GitHub-encouraged culture of squash-merges conflicts with right-sized PRs and informative commits, so it's understandable there is conflict in that area. I'm not a fan of the GitHub workflow that many have been trained by exposure to presume must be good practice. GitHub didn't design that workflow for optimal software engineering, nor have they ever really tried to improve it. They designed it to make it easier for newbies and more casual participants to join in "social coding".
Experience tells me that there are many who would disagree with your views and mine, though. Ironically, the most dogmatic people are sometimes those who haven't been at it for as long and think they know best. (Though all ages are definitely represented in the dogmatic pile). Perhaps it's the author of the article who is the newbie?!
Regarding file size, I've seen people insist on hundreds of tiny files to satisfy their interpretation of the SRP - single responsibility principle - to the extent a codebase is more difficult to read because half of the files are almost entirely boilerplate, pointing to boilerplate in other files. It makes some people happy, but doesn't always make a better codebase to work with. (Though for some things like, say, Glibc, that approach to systematic file layout is quite helpful, even when some files have only one non-comment line.)
I've also found when I see someone talking about uncomfortably small or large files, it's a mistake to presume what they have in mind. For some people, a 500 line source file is an enormous monstrosity that should never have existed. For others, 2000 lines (in the same language as previous) is a single good day's work containing one medium-size algorithm.
I also agree with you about about PR sizes, because I hold the view that the optimal unit of review (ie PR that makes sense) is larger than the optimal size of a well-explained logical commit. Although, the GitHub-encouraged culture of squash-merges conflicts with right-sized PRs and informative commits, so it's understandable there is conflict in that area. I'm not a fan of the GitHub workflow that many have been trained by exposure to presume must be good practice. GitHub didn't design that workflow for optimal software engineering, nor have they ever really tried to improve it. They designed it to make it easier for newbies and more casual participants to join in "social coding".
Experience tells me that there are many who would disagree with your views and mine, though. Ironically, the most dogmatic people are sometimes those who haven't been at it for as long and think they know best. (Though all ages are definitely represented in the dogmatic pile). Perhaps it's the author of the article who is the newbie?!