3 ms·

Couldn't one argue that most open-source projects are born as someone's "own little castle"? If people didn't build their own little castles, we wouldn't have,

Couldn't one argue that most open-source projects are born as someone's "own little castle"? If people didn't build their own little castles, we wouldn't have, for example, UNIX. I agree about hiring and working with people ("engineers") who take full advantage of existing tools and libraries; and can contribute to well-documented and battle-tested libraries in the community. But, as someone who (also) fits the description of a "programmer", I see the value in building our own little castles for fun and profit, to create libraries and frameworks for our own purposes. If existing solutions don't quite do the job, someone has to start these well-documented and battle-tested libraries to benefit the community - even if "only they can understand" it at the beginning. Perhaps the contrast and tension between these approaches are about the inherent risk of innovation. In a team environment, we don't want people inventing their own language or operating system from scratch - unless it directly contributes to the core business, which is rarely the case. For the largest tech companies, they can afford to risk the investment into innovation, to develop and maintain their own languages, frameworks, and libraries - if they bring competitive advantages. This caveat is often unclear though, whether this (re)invented thing actually delivers.

npstr 6y ago
Absolutely. Doing the right calls here is very hard, and takes a lot of experience. Btw - 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, and now the next one even saying these are two (or even more) different professions. I don't think that is the case. I think we need to understand the contexts, to know when each of the approaches is a likely better fit. Sometimes its very clear, and sometimes you won't know until much later. That's ok. I think it is important to document why a route was chosen, and evaluate if it is still the correct one, once more facts are available, or the environment changes. What I really don't like seeing is ranting about a chosen approach, without informing oneself first about how the decision was reached, and broad generalisations. Writing your own software, or just importing a lib, and the resulting side effects such as huge amounts of code to maintain or dependency hell, are tradeoffs - they are neither good nor evil - it all depends on the context. I'd love to see an article from the author drawing from their experience on making that kind of decisions.
- lioeters 6y ago
  > 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.

npstr 6y ago

Absolutely. Doing the right calls here is very hard, and takes a lot of experience. Btw - 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, and now the next one even saying these are two (or even more) different professions. I don't think that is the case. I think we need to understand the contexts, to know when each of the approaches is a likely better fit. Sometimes its very clear, and sometimes you won't know until much later. That's ok. I think it is important to document why a route was chosen, and evaluate if it is still the correct one, once more facts are available, or the environment changes. What I really don't like seeing is ranting about a chosen approach, without informing oneself first about how the decision was reached, and broad generalisations. Writing your own software, or just importing a lib, and the resulting side effects such as huge amounts of code to maintain or dependency hell, are tradeoffs - they are neither good nor evil - it all depends on the context. I'd love to see an article from the author drawing from their experience on making that kind of decisions.

lioeters 6y ago
> 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.