"If you are only one developer" suggests zero interests in being nuanced.
To be clear, this linked specifically to simplicity which I'm certainly in favor of emphasizing the importance of. But IME the exact opposite happens when people try to imitate Google overall in a smaller setting, where instead too much resources are spent on meta-issues instead of the product being developed.
I think you’re arguing with someone who isn’t here.
Nobody is endorsing the practices in TFA “because it’s Google”/in order to be like Google. Sure, people elsewhere make those claims all the time, and they’re wrong, but that’s not in evidence here that I can see.
The article does seem to come pretty close to universally applicable good ideas. Not because of where its author works, but because of the content.
> Nobody is endorsing the practices in TFA “because it’s Google”/in order to be like Google. Sure, people elsewhere make those claims all the time, and they’re wrong, but that’s not in evidence here that I can see.
I disagree, I think we can see this time and time a again. YMMV I guess. It's an encouragement to be vigilant for over-engineering when you don't need it because you're not google. I'm not saying that the content is bad, it's a worthy read. Just don't get overeager like the OOP craze phase where would attempt to bend everything into a maze of design pattern because people took whatever books they read way too far. Most of the chapters have YAGNI parts for smaller settings, but it's still worth knowing about what the next steps are.
This is a great text about considerations everyone operating software services should take to heart.
It applies regardless of if you deploy a monolith or several smaller servers.
If you are only one developer, it might apply in a smaller context.