[enriquto]

> Your time is valuable and much better spent building something no one else has yet.

I strongly disagree with this. I believe the exact opposite is true. Creation spurts from learning, so if you want to be creative it pays of to spend most of your time learning things that already exist. In the context of programming, this means implementing algorithms for which several other implementations already exist.

Sportsmen spend nearly all of their time training, and just a tiny (but very focused) amount of time competing. Likewise, scientists spend most of their time preparing experiments and reproducing results of others, and a tiny amount of time "creating". I do not believe that programmers can successfully escape this scheme. The best programmers I know, spend an inordinate amount of time rewriting well known algorithms (and oftentimes, improving them with slight variations).

[jariel]

How would one justify literally building something that someone has done very well, so that you can learn, literally by building something that's probably not as good.

I mean, on one's own time, this seems like rather a good thing to do.

But to say "Yeah, instead of something that works now 0 days work let's spend 3 months building something that may not work very well and we have to maintain" - is not a reasonable premise in most scenarios.

It defies the very point of trade specialization upon literally which the economy is built.

So while we should always be learning, learning in and of itself in most instances is not a good enough reason to do something at least at work.

[andrewjl]

It's simpler to justify if the development process is also seen as a knowledge acquisition process. Does the knowledge acquired by re-invention and its effect on subsequent effectiveness and or productivity outweigh the cost of time expended. In many cases, especially in a mature or stable environment, the answer is yes. It's also an attractive method of learning to people who like to think from first principles, as it involves developing a bottom-up understanding of whatever "the wheel" in this case is via practice.

I find that strong opinions either way on this question to be indicative of time preference. My own view is there's a time to do it and there's a time to avoid it. It becomes very valuable when ones navigating an unfamiliar area or is in the midst of a fundamental shift in the landscape. It's best to avoid it if the team or project is an a do-or-die scenario where certain milestones must be met to ensure it remains a viable team or project.

[jariel]

"as a knowledge acquisition process" so yes, if the module is a little bit core and you would rather have it internally, the added risk of time/quality/maintenance may be worth it. Sure.

[indrax]

>I mean, on one's own time, this seems like rather a good thing to do.

This is an interesting example of Conway's Law. If I hire a contractor for something, I'll want them to just import something that works, not try to explore things deeply. If I have a long term employee or cofounder, I'll want to encourage that experimentation and growth.