> I'm not against building your own castles (I love doing that, esp. in my free time) - I am just a bit triggered by the previous blog post arguing unconditiona

> I'm not against building your own castles (I love doing that, esp. in my free time) - I am just a bit triggered by the previous blog post arguing unconditionally for it.. Yeah, I totally hear you. God knows I've built not only "castles" but immense, complicated and unsustainable architectures (or balls of spaghetti); deadend frameworks that started deprecating the moment I wrote it; under-documented or -tested (or not at all!) libraries with unclear interfaces.. As much I love creating things from scratch, experience has taught me to be cautious and conservative when deciding to do so - especially in a company/team environment. It's almost always better to research first, study what exists in the ecosystem/community, and use available tools and building blocks. Many articles get posted on HN that describe how and why a company decided to build their own database, operating system, language, framework, or library. It's not as exciting to read or write about using "boring technology" to build stable, reliable systems with a decade-old, tried-and-tested framework. But this latter is, and should be, the standard approach: mostly "engineering", with just enough "programming" to glue and orchestrate it all together.