Tangential point: some of Google's practices have proved to be Bad Ideas™ in the long run anyway. Most of the practices of big companies did not usually contribute to their success; rather, they adopted those practices after their success, and sometimes because of their success.
Meanwhile, given some of the disastrous outcomes of various projects from Big Software, I tend to actually look more skeptically at any practice that Google, Facebook, Microsoft, Apple, Oracle, or the like follow.
So, don't solve problems you don't have, but if you do have or forsee them, don't assume that the solutions that mega-corporations use are necessarily smart to begin with.
I do have to add one other angle to the "don't be a perfectionist" topic. While one should definitely avoid "Imaginary Scaling Issues" (see image below), you should still structure your code to facilitate refactoring later!
Most of this is just loose coupling and DRY. For example, I may write a language parser that is dead simple, uses regex, and bumps along with dismal performance, but I design its API so I can easily swap it out for a better solution later if needed. I don't hardcode it.
I've lost track of how many times I blessed my past self for that practice.
Promised apropos image:
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Tangential point: some of Google's practices have proved to be Bad Ideas™ in the long run anyway. Most of the practices of big companies did not usually contribute to their success; rather, they adopted those practices after their success, and sometimes because of their success.
Meanwhile, given some of the disastrous outcomes of various projects from Big Software, I tend to actually look more skeptically at any practice that Google, Facebook, Microsoft, Apple, Oracle, or the like follow.
So, don't solve problems you don't have, but if you do have or forsee them, don't assume that the solutions that mega-corporations use are necessarily smart to begin with.
I do have to add one other angle to the "don't be a perfectionist" topic. While one should definitely avoid "Imaginary Scaling Issues" (see image below), you should still structure your code to facilitate refactoring later!
Most of this is just loose coupling and DRY. For example, I may write a language parser that is dead simple, uses regex, and bumps along with dismal performance, but I design its API so I can easily swap it out for a better solution later if needed. I don't hardcode it.
I've lost track of how many times I blessed my past self for that practice.
Promised apropos image: