> I can write a hashtable implementation in an afternoon, but it's going to have bugs

If it has any bugs that would surface in a year of production (while the dependency version wouldn't) then you didn't write an equivalent in an afternoon.

The advice, if it's to be useful at all, must be things that you could completely replace in the same quality, in an afternoon.

It's the left-pads and is-odds, to begin with.

I'd extend "afternoon" to "half a week", but in general I agree with OP.

> Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version.

The meaning of "afternoon work" should be considered "of good enough quality". Tests, structure, reasonable docs, all that. It shouldn't be a fastest written something, it should be a normal code.

> and still not achieve the performance of the pre-built version.

Some losses in performance are acceptable for greater visibility and better fit for the project. If you need non-trivial performance gains - well, those are also achievable by code, are you sure you can actually write such code in a few days?

> Find a bug in the dependency? Submit a patch.

That's the point. To submit a good patch, you have to internalize the system. It's easier to do if the system is yours - doesn't do much except what you need.

> Worried about the dependency changing? Lock the version.

Now you've locked yourself out of upstream bug fixes.

> Don't reinvent the wheel.

Here is a wheel patented in 1972 in US, with noticeable benefits over the traditional idea: https://en.wikipedia.org/wiki/Mecanum_wheel :) .

We do reinvent the wheel whenever we need to have an actual wheel for a device, not an abstract concept. Similarly, we write for loops, "reinventing" them for our specific purpose. Those are all different wheels, loops and needs. Don't mistake the "idea" of a hashtable with an implementation.

> This is horrible advice. There's a reason that you don't write your own hashtable implementations.

Of course you do and release(d) them as open source (public domain). Take Java - it has decent a HashMap but it's node based. It's memory inefficient to a point its nodes and arrays are top 3 of memory consumption. An array based hashtable takes around 3.6 times less memory for larger ones (on 4bytes compressed pointers) and over 10 times less for smaller ones. Perf. wise it's on par or better as well (nowadays architecture is heavily driven by locality and access patterns)

Also you make your code so it can switch between both on the fly, if need be.

Never use a dependency if you could write something of equivalent quality in afternoon. Seems reasonable enough.

> Worried about the dependency changing? Lock the version.

And get p0wned a year later when some security researcher finds a vulnerability in code that you don't even use, but pulled in as part of that dependency.