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.