First Rule of Programming Is Don't Program

- Buy an off the shelf program and take 3 hours to read their proprietary API for extra functionality. Then learn that you cannot integrate it into the current system (because of licensing, data format, missing features). Since you cannot make changes to the off the shelf program, you have to rewrite most of the existing code, just to satisfy the programs expectation. Or spend a month writing software that does a two-way sync between the proprietary API and the current data. Then learn that the API documentation is not complete/correct, then that new versions come out once a year - whether you need a bugfix or not.

I agree with the rest though... if there is a library, use it. Pay for it if you really need it. Just make sure you can modify it when needed and that you can do what the api/docs says you can - otherwise the software you bought is worth nothing as soon as you hit a problem, or you spend more money working around the problems than rewriting the software from scratch would cost.

If everybody would reason the way you did then we'd be stuck at version 1.0 of just about everything because nobody would get off their asses to do something new every now and then.

So it's a treshold problem. At some point the tension between that which is available and that which has to be done becomes so large that someone will stand up and says 'let's fix that, once and for all'. This person will then put in an enormous amount of time on top of what it would probably have taken to fix just the original problem.

And that's exactly how progress is made in the software world.

So, the premise you make is an idealistic one, in an ideal world, such libraries and bits and pieces should be available, for sale, well documented and 100% applicable.

In reality that is definitely not the case.

You are right that many people will fall for the 'let me do that' temptation when in fact they would be better served by using something off the shelf.

To keep your engineering analogy alive: If an engineer working on a car even could go and make his own bolts then that would be the road to total madness. There is lots of standardization and materials knowledge available to 'hard' engineers that is simply not there for 'soft' engineers, and because the price of the tooling is essentially zero the threshold for re-implementation (hopefully in a novel and better way) is very low.

Maybe it's too low, but that's a policy decision, not a technical one.

And if you are not under a deadline and simple trying to get the hang of stuff nothing will teach you better than to re-implement some of the better understood algorithms, especially queues, lists stacks and so on.

These are the staple of many larger structures and to understand them well (and how tricky they are to get right) is essential knowledge.

Consider keeping such a chunk of code around only long enough to get the product shipped and paying for itself. At that point, make an attempt to justify keeping it around, especially after seeing how it fits into the big picture of your product.