I firmly think there are two kinds of knowledge: the one you have because someone explained to you something and you understood it, and the one you get because you bang yourself against the same problems someone had decades ago and you find out the best solution for the problem, which of course it’s the same they found at their time … and trust me, this one is invaluable.

Sometimes I come across answers on the Internet to questions posed in the form of:

hey why implementing it yourself? Just use a database! or there's the whole STL library that can do this for you, why you should implement a RB-tree by yourself? and so on, I’m sure you know what I’m talking about.

Sometimes these answers are valid, and sometimes they aren’t. Sometimes theoretical knowledge is just that theoretical knowledge, while practical, hands-on experience makes a real difference. That’s one of the reasons behind the idea for this blog post.

How can you truly grasp why a hash table needs rehashing if you’ve never built one yourself and optimized it for a real-world application?

How can you effectively understand and utilize SQL indexes without knowing data cardinality and its impact on binary tree structures?

How can you genuinely appreciate the complexities of OS scheduling without attempting to implement a basic kernel and experiencing the challenges firsthand?

How can you fully comprehend the distinction between reserved and committed memory if you’ve never created even the simplest memory allocator just to experiment with it?

In everyday life, it’s similar: you can hear countless stories from others, and they’ll certainly teach you a lot. But you’ll also make many mistakes of your own, which will teach you even more—often involving challenges you didn’t see coming, problems you encounter for the first time, with no one around who has experienced exactly what you’re going through in your unique time.

I remember when I was leaving one company, the project’s technical director told me he wished me plenty of mistakes. Only now do I understand what he meant. Only now do I realize that the mistakes I’ve made have taught me so much—enough that I’m much wiser now and often understand things at their core.

How did he know? I’m grateful for his words and for everything they brought me.

Conclusion:

So next time someone asks why you keep reinventing the wheel, you can give them two solid reasons:

• I genuinely want to understand how it works

• Progress only happens when someone is willing to push the boundaries

My site is free of ads and trackers. Was this post helpful to you? Why not