Roughly a year ago McKinsey and Company published an article entitled ‘Yes, you can measure software developer productivity’. It was a controversial piece, but did McKinsey introduce a genuine innovation?
Relying on manually reviewed pull requests to ensure that coding conventions are being followed? If you live in .NET land, don’t. Use custom Roslyn analyzers to spot and fix issues ahead of your CI pipeline.
Relying on manually reviewed pull requests to ensure that architecture constraints are being followed? Don’t. Instead, define the rules of your architecture and write unit tests to ensure they are not broken.
I expand on a conversation I had a couple of months ago, where I scoffed at workflows that manually approve pull requests before merging them without really explaining why.
In response to a question at work a few years ago I wrote a short software architecture reading list. It’s not comprehensive and could be more up to date, but it’s proven useful over the last couple of years as an answer to ‘where do I even start?’ type questions.