The Importance of Knowledge, Documentation, and Trade-offs in Engineering Choices
In the world of engineering and technology, there is often a lot of debate about the best infrastructure choices for different projects and startups. One common take is that engineers copy the infrastructure of FAANG (Facebook, Amazon, Apple, Netflix, and Google) companies because they want to appear cool, even if their own needs are completely different. However, there is another perspective to consider.
In a recent discussion, one engineer pointed out that the choice to copy FAANG infrastructure is not just about trying to be trendy, but also about knowledge and documentation. If they want to set up an infinitely scalable queue-based architecture, for example, there are numerous high-quality guides, tutorials, and white papers available that show them exactly how to do it. While maintenance may be higher with such a setup, they can quickly get up and running by copying and pasting commands, code, and configurations from reputable sources.
On the other hand, if they want to use a lesser-known feature like NOTIFY in PostgreSQL, finding reliable documentation and resources can be much more challenging. The engineer mentioned searching for answers on Stack Overflow, only to find unanswered questions and a GitHub gist with code but no context. This lack of comprehensive documentation can be a significant barrier to implementing certain features or technologies, leading engineers to opt for more well-documented and widely-used options.
The engineer further explained that for them, the choice between a simple and non-scalable solution like using PostgreSQL or a complex but scalable solution like Redis or SQS is not just about blindly following the latest tech trends. It’s about finding a solution that allows them to implement their project quickly and efficiently, considering the knowledge and resources available.
They emphasized that while there is an objective trade-off to be made between scalability and simplicity, another crucial dimension to consider is familiarity and implementation speed using available documentation and examples. This is particularly relevant in startup environments where time is often a critical constraint.
The engineer also highlighted the potential risks and challenges associated with choosing complex and scalable solutions without considering the specific needs of the project. They pointed out that maintenance becomes a significant burden, and for small startups with limited resources, it can even become a determining factor in their success or failure.
Additionally, they discussed the importance of flexibility in the development process. While scalable solutions may offer significant benefits, they can also limit the ability to make changes quickly and easily if the original design doesn’t work as expected. By contrast, using simpler and more flexible solutions like PostgreSQL allows for more agile development and easier changes.
Ultimately, the engineer’s argument shows that when it comes to making infrastructure choices, it’s essential to consider knowledge, documentation, trade-offs, and the specific needs of the project. While copying FAANG infrastructure may seem like following the latest trend, it can often be a reasonable choice based on the available resources and familiarity with the technology. At the same time, it’s crucial to evaluate the long-term maintenance requirements and potential challenges that could arise from choosing complex and scalable solutions without careful consideration.
In conclusion, the debate about engineers copying FAANG infrastructure is multifaceted. It’s not just about trying to be cool, but also about leveraging existing knowledge and documentation to implement projects efficiently. In the end, every engineering choice involves trade-offs and considerations that go beyond the surface-level perception of following industry giants.
Disclaimer: Don’t take anything on this website seriously. This website is a sandbox for generated content and experimenting with bots. Content may contain errors and untruths.
Author Eliza Ng