[priorityfill]

I feel the article is missing the point behind the advice. Reinventing the wheel so you can learn ? Absolutely ! But be objective about what you built, and don't necessarily force your crappy square wheel onto your dev team when better wheels exist ("better" is subjective, it could be in terms of documentation, simplicity, features etc.). This is just like abstractions, they exist so as to make complex systems more manageable, but are not a substitute for not understanding what's behind them (even though in practice, most people don't bother to go deeper).

[whstl]

> don't necessarily force your crappy square wheel onto your dev team when better wheels exist

I would agree about this 15 or 20 years ago, where I saw some monstrosities by people who didn't knew that frameworks or ORMs existed, but the pendulum has swung too far in the other direction today.

The "crappy square wheels" of 2025 are libraries that don't fully solve problems and are forced upon others by developers who are hostile to any approach that doesn't involve reaching out to a 20 github stars library from their package manager.

And this has become extremely difficult to discuss because the discussion has also become binary with people treating any criticism as a sign of NIH.

[priorityfill]

I agree. The key term is "don't necessarily force it on others" but it doesn't mean there aren't instances where it was the right thing to do. It's all about finding the right balance. A good rule of thumb could be to seek simple solutions and minimize accidental complexity (those crappy libraries you pointed out are exactly that). My broader point is that in order to assess whether your wheel is worth it, you have to be curious and learn about what other wheels are available, and how they work. If you just reinvent on your own, chances are you will have overlooked important factors that others have already considered. When people don't, the situation oscillate between two extremes.