I've reinvented my own wheel in a particular niche. I didn't set out to do that, but I rejected the existing state of the art as fundamentally misguided. Then, I attempted to divide-and-conquer my particular problem, something that is conventionally considered impossible.
Against all odds, I not only succeeded (mostly thanks to ignorance and stubbornness), but my wheel turns out to be unbelievably good at what it does. Possibly even world-class. After further experimentation, it also enables feats that can only be described as pure heresy with troubling ease. Time passes and some people from that niche start picking up my wheel. They all hold it wrong at the beginning because it's so alien, but once they get the hang of it they never go back.
I get bug reports and feature requests from all over the world for the oddest of use-cases and workflows. I have deep, in-depth technical discussions with brilliant people I would've never met otherwise. I've witnessed achievements done by others with my wheel beyond my wildest dreams. I discover things that keep me awake at night. I get kicks out of melting down the brains of my uninitiated coworkers and colleagues explaining what my wheel does and what I can do with it.
Don't be afraid to reinvent the wheel. You never know what crazy, wild path it might roll you down to.
It's a Ghidra extension that can export relocatable object files from any program selection. In other words, it reverses the work done by a linker.
I originally built this as part of a video game decompilation project, having rejected the matching decompilation process used by the community at large. I still needed a way to divide and conquer the problem, which is how I got the funny idea of dividing programs. That allows a particular style of decompilation project I call Ship of Theseus: reimplementing chunks of a program one piece at a time and letting the linker stitch everything back together at every step, until you've replaced all the original binary code with reimplemented source code.
It's an exquisitely deep and complex topic, chock-full of ABI tidbits and toolchains shenanigans. There's next to no literature on this and it's antithetical to anything one might learn in CS 101. The technique itself is as powerful as it is esoteric, but I like to think that any reverse-engineer can leverage it with my tooling.
In particular, resynthesizing relocations algorithmically is one of those problems subject to the Pareto principle, where getting 80% of them right is reasonably easy but whittling down the last 20% is punishingly hard. Since I refuse to manually annotate them, I've had to relentlessly improve my analyzers until they get every last corner case right. It's by far the most challenging and exacting software engineering problem I've ever tackled, one that suffers no hacks or shortcuts.
Once I got it working, I then proceeded in the name of science to commit countless crimes against computer science with it (some of those achievements are documented on my blog). Cross-delinking in particular, that is delinking an artifact to a different platform that it originates from, is particularly mind-bending ; I've had some successes with it, but I sadly currently lack the tooling to bring this to its logical conclusion: Mad Max, but with program bits instead of car parts.
Ironically, most of my users are using it for matching decompilation projects: they delink object files from an artifact, then typically launch objdiff and try to create a source file that, when compiled, generates an object file that is equivalent to the one they ripped out of the artifact. I did not expect that to happen at all since I've built this tool to specifically not do this, but I guess when everything's a nail, people will manage to wield anything as a hammer.
elorant · 32m ago
In my almost 15 years in this community this is the first comment where I don’t have a fucking clue of what is described.
One of the most important reasons to reinvent the wheel which is is not mentioned by the author is to avoid adding complexity through unnecessary dependencies.
underdeserver · 2h ago
100% this, and I'll add that libraries become popular because they solve an issue in many different scenarios.
That menas that almost by definition, if a library is popular, it contains huge amounts of code that just isn't relevant to your use case.
The tradeoff should be whether you can code your version quickly (assuming it's not a crypto library, never roll your own crypto), because if you can, you'll be more familiar with it and carry a smaller dependency.
jfengel · 1h ago
Unfortunately, if you depend on any libraries, there's a decent chance one of them depends on some support library. Possibly for just one function. And then your build tool downloads the entire Internet.
thfuran · 1h ago
That depends a lot on your language / build system. The easier it is to add a dependency, the more likely that is to be how they work, broadly speaking.
rjsw · 1h ago
A ruby application that I will soon need to use downloads 227 packages.
jonny211 · 21m ago
That's wild. Which gem is it? Something AWS?
No comments yet
zzo38computer · 2h ago
I also agree to avoid adding complexity through unnecessary dependencies.
> if a library is popular, it contains huge amounts of code that just isn't relevant to your use case.
It is true that many libraries do contain such code, whether or not they have dependencies. For example, SQLite does not have any dependencies but does have code that is not necessarily relevant to your use. However, some programs (including SQLite) have conditional compilation; that sometimes helps, but in many cases it is not suitable, since it is still the same program and conditional compilation does not change it into an entirely different one which is more suitable for your use.
Also, I find often that programs include some features that I do not want and exclude many others, and existing programs may be difficult to change to do it. So that might be another reason to write my own, too.
bitwize · 56m ago
"Never roll your own crypto" usually means "never devise your own crypto algorithms". Implementing an established algorithm yourself is OK provided you can prove your implementation works correctly. And... well, as Heartbleed showed, that's hard even with established crypto libraries.
jeff-davis · 21m ago
Note that there are quite a few ways that crypto implementations can be insecure even if it's proven to be "correct" (in terms of inputs and outputs). For instance, it may leak information through timing, or by failing to clear sensitive memory due to a compiler optimization.
kortilla · 2h ago
That’s true for frameworks but not good libraries.
skinowski · 6m ago
+1, also sometimes to avoid complexity due to unnecessary abstractions/modularity, etc.
efavdb · 17m ago
Another: getting good at invention / research is a skill that can be honed through practice - and you can practice on previously solved problems.
anyonecancode · 54m ago
Less "reinventing" the wheel and more "uncovering the wheel."
megadragon9 · 2h ago
Thanks for this inspiring essay, I couldn’t agree more that “reinventing for insight” is one of the best ways to learn. I had a similar experience couple months ago when I built an entire PyTorch-style machine learning library [1] from scratch, using nothing but Python and NumPy. I started with a tiny autograd engine, then gradually created layer modules, optimizers, data loaders etc... I simply wanted to learn machine learning from first principles. Along the way I attempted to reproduce classical convnets [2] all the way to a toy GPT-2 [3] using the library I built. It definitely helped me understand how machine learning worked underneath the hood without all the fancy abstractions that PyTorch/TensorFlow provides. Kinda like reinventing the car using the wheel I reinvented :)
Reinventing the wheel is the best way to learn. But imo that's really the only context where you should.
I love my rabbit holes, but at work, it's often not viable to explore them given deadlines and other constraints. If you want your wheel to be used in production though, it better be a good wheel, better than the existing products.
rTX5CMRXIfFG · 24m ago
It's not really the best way to learn because it's the most expensive and time-consuming. What needs to be learned just needs to be well-documented and possible to tinker with, and clarity of communicating knowledge is a problem on its own, but you shouldn't have to build the whole thing from scratch.
epolanski · 1h ago
99% of the people that reinvent wheels at work don't know how the wheel they don't like is even made and why it has the compromises it has.
chad_c · 24m ago
I’m reminded of Chesterton’s Fence [1]. I just explained this to a coworker that was proud of indiscriminately eliminating 200+ positions.
If you're working in a startup I hope you'll completely ignore this advice, unless the particular wheel you're reinventing is core to the product/service your startup makes. If it's not, you're likely just setting your runway on fire and crashing the plane before takeoff.
epolanski · 1h ago
You still want to build a startup with people that know how to build wheels, and thus have done it professionally, in oss or personal projects.
bawis · 52m ago
I guess it's more like an advice for personal wheels, not professional ones.
ppqqrr · 27m ago
the obsessive narrative against redundancy has been the blight of our times. people are copies of each other, they eat the same food, work the same job, have the same needs. if you follow the Big Wheel propaganda to its logical conclusion, you’ll have as your ideal a very specialized person who serves a very specific needs of some (probably) rich people, but knows or enjoys absolutely nothing else: never cooks, grows, loves anything, because those things are redundant.
bigyabai · 1m ago
"Don't reinvent the wheel" doesn't necessarily imply you shouldn't question anything, or even that you always have to take the path of least resistance. If your car tire pops, you should consider all of your wheel options. You just shouldn't reinvent the wheel; they give you a spare for a reason, and anything you can design or manufacture is going to be worse than the one from the factory.
If reinventing the wheel was a lucrative business, people would do it. But the rewards seldom justify the invested effort, there isn't a huge pre-market futures trade that's going to go down the drain if Apple announces the iWheel 2.
kayodelycaon · 26m ago
You need to know when not to reinvent the wheel.
I’ve certainly done it at work because I didn’t have time (or desire) to learn a library.
But sometimes you have to understand the wheel to reinvent it.
I’m not gonna let a someone roll their own user authentication and authorization system in a rails application.
There’s so many moving pieces you won’t even think about and there’s gems that solve this extremely well. Study the gem and you will learn a lot more. Then reinvent the wheel.
awinter-py · 2h ago
engage rationally with build vs buy decisions
accept that there are compatibility boundaries such that it is sometimes quicker to create a new X than locate it on the market, or that X is too expensive and it's time to pursue vertical integration
but teams who can't do build vs buy properly are kind of doomed, sentenced to endless cycles of Not Invented Here syndrome which block other work.
if you're in a meeting and someone says 'we can't launch our website until we develop a platform-native way to host websites' you're in the wrong part of the curve
Waterluvian · 52m ago
90% of the time it’s wrong to “reinvent the wheel.” If you chose this option dogmatically, you’d be making the right choice 90% of the time. But this also represents a below average outcome as a one-sided die would roll this choice right 90% of the time, too.
Your job as the decision-making engineer is to develop the expertise to be able to make the right choice more than 95% of the time.
Ekaros · 2h ago
Go ahead build your own wheel. But often it is better just to use one already made.
There is lot of complexity that mature wheels have taken into account or have had to solve and you are likely miss lot of it. Not that building your own does not help you to understand it.
Still, I wouldn't replace wheels on my car with ones I made myself from scratch... Just like I wouldn't replace reasonable complex library.
imiric · 2h ago
Precisely.
While sometimes reinventing the wheel is a useful exercise, as TFA lays out, this is often a symptom of a larger Not Invented Here mentality. This is generally a harmful tendency in some organizations that leads to derailing project deadlines, and misdirecting resources towards building and maintaining software that is not core to the company's mission.
So in most cases the advice to not reinvent the wheel is more helpful. Deciding to ignore it, especially within a corporate environment, should be backed by very good reasons.
turtleyacht · 2h ago
> Reinvent for insight. Reuse for impact.
When Primeagen was once interviewed, he built out a whole Java architecture; the interviewer asked him, "Have you heard of grep?" And that started a journey.
If it were to happen to me, feels like a full circle to go from glue and dependencies to pointers and data structures. A welcome reverie.
semiinfinitely · 1h ago
People advise not to "reinvent the wheel" because doing so imbues you with the ability to create new things yourself- increasing your agency and power thereby relatively decreasing theirs. Also it often comes at some expense to them if they have some claim to your time eg boss/coworker.
isaacremuant · 55m ago
I love how you selfishly think about your agency as if there was no team involved dealing with your "snowflake creation".
When I give this advice it usually means I don't think the output is better than the existing thing and the dependency cost is better paid in the form of integration.I probably don't think you'll really maintain your creation or think about others using it when you do.
As long as we are throwing shitty incentives around.
But on a more neutral note, it's a tradeoff with many moving parts. Different choices for different scenarios.
almosthere · 47m ago
People that work at Radial, Michelin, Good Year, etc... probably are sick of hearing it.
zero-sharp · 2h ago
So you ignored the context surrounding this piece of advice?
Yea, reinventing the wheel is a great way to learn. You're not going to hear an educator tell you to not reinvent the wheel.
tehnub · 2h ago
Yep, not reinventing the wheel is advice you should consider in a business context, not when you’re programming for fun, although I’m sure there are hordes of people giving this advice outside of the business context and perhaps that’s what OP is responding to.
richardjennings · 2h ago
I very much agree with the Author. "Do not reinvent the wheel" is unfortunate in that it muddles several things into one piece of subjective advice.
The advice as I would give it is:
"Try to re-invent the things you are interested in".
"Do not underestimate the value of the continued interaction between reality and established solutions."
mcnamaratw · 3h ago
Yeah. Ok. You want the fine print? Reinvent the wheel … for your own learning and fun. Or invent a different kind of wheel.
Don’t reinvent the wheel on a tight deadline while the rest of the team does useful work. Don’t reinvent the wheel and then expect to be rewarded or respected as if you had really invented something.
baxtr · 2h ago
"Sometimes it’s a good idea to reinvent the wheel" would have been a better title.
demirbey05 · 2h ago
If you invent someting better, you can get reward, lots of examples out there.
mcnamaratw · 2h ago
Sure. But inventing something better is not reinventing the wheel. Those are two completely different activities.
nssnsjsjsjs · 1h ago
It doesn't have to be not better though. The wheel reinventor has hindsight.
nssnsjsjsjs · 1h ago
Oh I totally assumed this applied to passion projects, making your own K8s on weekends kind of thing.
hoppp · 3h ago
You can reinvent the wheel for a specialized niche case but just dont expect many people to use it.
low_tech_punk · 2h ago
I don't like vibe coding in general, but it is surprisingly a good tool to reinvent the wheel. Claude Code team allegedly built their own markdown rendering with Claude because the existing renderers don't meet their needs.
graypegg · 2h ago
I mean, the phrase isn't "Don't reinvent A wheel". I do feel like it's good advice as-is! To me, "reinvent" implies starting from nothing (inventing), again: If you can learn from why THE wheel is the way it is, you can make A better wheel. Yes it's good for learning, but it's also good advice for focusing on building things as a participant in our own shared history of invention, not trying to be the main character.
random3 · 1h ago
And the even more general advice: "First, break all the rules"
(not (necessarily) the book).
Sure, making a new wheel is fine if you're never actually going to use it. But if you're actually being serious, remember that you'll have to maintain it.
jspdown · 1h ago
There's no free meal and adding a dependency is far from being free. Each dependency you add needs to be carefully reviewed, each of its update as well.
Though, apparently many people just YOLO this part.
priorityfill · 2h ago
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).
sfpotter · 1h ago
So many bitter and jaded people in this thread.
moron4hire · 3h ago
I've long said, I hate when people say, "don't reinvent the wheel." Even for the literal wheel, I know of at least 3 times it was usefully reinvented in just the last 20 years.
People who say "don't reinvent the wheel" should come up with something new to say.
But they can't, because they hate innovation so much.
hoppp · 3h ago
Wheels are constantly under development and are improving, but they are still derived from the previous concept, not a new invention
I think reinventing the wheel would be like creating a wheel that does not spin or somethin... some youtubers have done it actually. Its fun to mess around with but hard to create something valuable.
Ekaros · 2h ago
Or they have noticed that some new wheels are not great. One example of wheel was this electric bicycle with massive hub. In essence almost as big constructions of bearings as the wheel itself... Horrible reliability and efficiency. Did look cool.
mcnamaratw · 3h ago
I’m sorry but you’re mistaken. The wheel was invented thousands of years ago.
OtomotO · 1h ago
These discussions (in the comments) tend to become this "to write everything yourself or not" discussions which are extreme in nature and very binary. While reality is way more nuanced.
Why do you add a dependency? Because you need a certain functionality.
The alternative to adding this dependency is to write the code yourself.
That is totally feasible for a lot of dependencies.
That is totally infeasible for a lot of dependencies.
It's a trade off, as always. The fact is, that most of us, who do this for a living, need to ensure that our software runs and continues to run and may be adapted in a timely manner, when new requests come in from the client/owner.
Using dependencies or not using depdencencies isn't gonna change that.
Now, granted, some ecosystems are a bit extreme on the "let's add a dependency for this 1 line of code."
On the other hand: should I really roll my own crypto? (Jk)
Should I really write those 5000 lines of well tested code myself, just because I can? And because MAYBE it's not touched in a month from now?
Every (later executed) line I add to the project, be it one written by myself or an external dependency, becomes part of the code. So I have to be able to maintain it. Might be easier if I write it myself. Might be way more difficult and time consuming if I write it myself...
I have so many tasks to do and while I enjoy coding, I have to make my top priority a working system.
So should I mindlessly add dependencies? Of course not!
Should I just reinvent the whole world? Of course not! (Unless the client absolutely wants me to. And pays me to do it)
Blikkentrekker · 2h ago
Ehh, I always took the “don't reinvent the wheel” advice in context of “wheels” being very simple things that everyone can create but no one wants to spend time on. It's typically not really a learning exercise to say implement quicksort or some hash table; it simply takes time.
You will also rarely build a better implementation of these things than whatever is in the standard library or even some other library that already exists. If anything, it's better to, if one have a better idea, to contribute one's patches there.
sfpotter · 54m ago
It actually isn't that hard to come up with something better than what's in a standard library, but that requires understanding what better means for what you're working on. That's the hard part. In my experience, people who say "don't reinvent the wheel" are also the people who have the poorest understanding of requirements: what "better" means.
A standard library data strucute or algorithm has to be something for everyone, so it can't be truly great at a specific thing. If you understand your specific use case extremely well it (and are competent...) it can be very easy to run circles around the standard library.
Against all odds, I not only succeeded (mostly thanks to ignorance and stubbornness), but my wheel turns out to be unbelievably good at what it does. Possibly even world-class. After further experimentation, it also enables feats that can only be described as pure heresy with troubling ease. Time passes and some people from that niche start picking up my wheel. They all hold it wrong at the beginning because it's so alien, but once they get the hang of it they never go back.
I get bug reports and feature requests from all over the world for the oddest of use-cases and workflows. I have deep, in-depth technical discussions with brilliant people I would've never met otherwise. I've witnessed achievements done by others with my wheel beyond my wildest dreams. I discover things that keep me awake at night. I get kicks out of melting down the brains of my uninitiated coworkers and colleagues explaining what my wheel does and what I can do with it.
Don't be afraid to reinvent the wheel. You never know what crazy, wild path it might roll you down to.
It's a Ghidra extension that can export relocatable object files from any program selection. In other words, it reverses the work done by a linker.
I originally built this as part of a video game decompilation project, having rejected the matching decompilation process used by the community at large. I still needed a way to divide and conquer the problem, which is how I got the funny idea of dividing programs. That allows a particular style of decompilation project I call Ship of Theseus: reimplementing chunks of a program one piece at a time and letting the linker stitch everything back together at every step, until you've replaced all the original binary code with reimplemented source code.
It's an exquisitely deep and complex topic, chock-full of ABI tidbits and toolchains shenanigans. There's next to no literature on this and it's antithetical to anything one might learn in CS 101. The technique itself is as powerful as it is esoteric, but I like to think that any reverse-engineer can leverage it with my tooling.
In particular, resynthesizing relocations algorithmically is one of those problems subject to the Pareto principle, where getting 80% of them right is reasonably easy but whittling down the last 20% is punishingly hard. Since I refuse to manually annotate them, I've had to relentlessly improve my analyzers until they get every last corner case right. It's by far the most challenging and exacting software engineering problem I've ever tackled, one that suffers no hacks or shortcuts.
Once I got it working, I then proceeded in the name of science to commit countless crimes against computer science with it (some of those achievements are documented on my blog). Cross-delinking in particular, that is delinking an artifact to a different platform that it originates from, is particularly mind-bending ; I've had some successes with it, but I sadly currently lack the tooling to bring this to its logical conclusion: Mad Max, but with program bits instead of car parts.
Ironically, most of my users are using it for matching decompilation projects: they delink object files from an artifact, then typically launch objdiff and try to create a source file that, when compiled, generates an object file that is equivalent to the one they ripped out of the artifact. I did not expect that to happen at all since I've built this tool to specifically not do this, but I guess when everything's a nail, people will manage to wield anything as a hammer.
No comments yet
That menas that almost by definition, if a library is popular, it contains huge amounts of code that just isn't relevant to your use case.
The tradeoff should be whether you can code your version quickly (assuming it's not a crypto library, never roll your own crypto), because if you can, you'll be more familiar with it and carry a smaller dependency.
No comments yet
> if a library is popular, it contains huge amounts of code that just isn't relevant to your use case.
It is true that many libraries do contain such code, whether or not they have dependencies. For example, SQLite does not have any dependencies but does have code that is not necessarily relevant to your use. However, some programs (including SQLite) have conditional compilation; that sometimes helps, but in many cases it is not suitable, since it is still the same program and conditional compilation does not change it into an entirely different one which is more suitable for your use.
Also, I find often that programs include some features that I do not want and exclude many others, and existing programs may be difficult to change to do it. So that might be another reason to write my own, too.
[1] https://github.com/workofart/ml-by-hand
[2] https://github.com/workofart/ml-by-hand/blob/main/examples/c...
[3] https://github.com/workofart/ml-by-hand/blob/main/examples/g...
I love my rabbit holes, but at work, it's often not viable to explore them given deadlines and other constraints. If you want your wheel to be used in production though, it better be a good wheel, better than the existing products.
[1] https://www.lesswrong.com/w/chesterton-s-fence
If reinventing the wheel was a lucrative business, people would do it. But the rewards seldom justify the invested effort, there isn't a huge pre-market futures trade that's going to go down the drain if Apple announces the iWheel 2.
I’ve certainly done it at work because I didn’t have time (or desire) to learn a library.
But sometimes you have to understand the wheel to reinvent it.
I’m not gonna let a someone roll their own user authentication and authorization system in a rails application.
There’s so many moving pieces you won’t even think about and there’s gems that solve this extremely well. Study the gem and you will learn a lot more. Then reinvent the wheel.
accept that there are compatibility boundaries such that it is sometimes quicker to create a new X than locate it on the market, or that X is too expensive and it's time to pursue vertical integration
but teams who can't do build vs buy properly are kind of doomed, sentenced to endless cycles of Not Invented Here syndrome which block other work.
if you're in a meeting and someone says 'we can't launch our website until we develop a platform-native way to host websites' you're in the wrong part of the curve
Your job as the decision-making engineer is to develop the expertise to be able to make the right choice more than 95% of the time.
There is lot of complexity that mature wheels have taken into account or have had to solve and you are likely miss lot of it. Not that building your own does not help you to understand it.
Still, I wouldn't replace wheels on my car with ones I made myself from scratch... Just like I wouldn't replace reasonable complex library.
While sometimes reinventing the wheel is a useful exercise, as TFA lays out, this is often a symptom of a larger Not Invented Here mentality. This is generally a harmful tendency in some organizations that leads to derailing project deadlines, and misdirecting resources towards building and maintaining software that is not core to the company's mission.
So in most cases the advice to not reinvent the wheel is more helpful. Deciding to ignore it, especially within a corporate environment, should be backed by very good reasons.
When Primeagen was once interviewed, he built out a whole Java architecture; the interviewer asked him, "Have you heard of grep?" And that started a journey.
If it were to happen to me, feels like a full circle to go from glue and dependencies to pointers and data structures. A welcome reverie.
When I give this advice it usually means I don't think the output is better than the existing thing and the dependency cost is better paid in the form of integration.I probably don't think you'll really maintain your creation or think about others using it when you do.
As long as we are throwing shitty incentives around.
But on a more neutral note, it's a tradeoff with many moving parts. Different choices for different scenarios.
Yea, reinventing the wheel is a great way to learn. You're not going to hear an educator tell you to not reinvent the wheel.
The advice as I would give it is:
"Try to re-invent the things you are interested in".
"Do not underestimate the value of the continued interaction between reality and established solutions."
Don’t reinvent the wheel on a tight deadline while the rest of the team does useful work. Don’t reinvent the wheel and then expect to be rewarded or respected as if you had really invented something.
People who say "don't reinvent the wheel" should come up with something new to say.
But they can't, because they hate innovation so much.
I think reinventing the wheel would be like creating a wheel that does not spin or somethin... some youtubers have done it actually. Its fun to mess around with but hard to create something valuable.
Why do you add a dependency? Because you need a certain functionality.
The alternative to adding this dependency is to write the code yourself.
That is totally feasible for a lot of dependencies.
That is totally infeasible for a lot of dependencies.
It's a trade off, as always. The fact is, that most of us, who do this for a living, need to ensure that our software runs and continues to run and may be adapted in a timely manner, when new requests come in from the client/owner.
Using dependencies or not using depdencencies isn't gonna change that.
Now, granted, some ecosystems are a bit extreme on the "let's add a dependency for this 1 line of code."
On the other hand: should I really roll my own crypto? (Jk)
Should I really write those 5000 lines of well tested code myself, just because I can? And because MAYBE it's not touched in a month from now?
Every (later executed) line I add to the project, be it one written by myself or an external dependency, becomes part of the code. So I have to be able to maintain it. Might be easier if I write it myself. Might be way more difficult and time consuming if I write it myself...
I have so many tasks to do and while I enjoy coding, I have to make my top priority a working system.
So should I mindlessly add dependencies? Of course not!
Should I just reinvent the whole world? Of course not! (Unless the client absolutely wants me to. And pays me to do it)
You will also rarely build a better implementation of these things than whatever is in the standard library or even some other library that already exists. If anything, it's better to, if one have a better idea, to contribute one's patches there.
A standard library data strucute or algorithm has to be something for everyone, so it can't be truly great at a specific thing. If you understand your specific use case extremely well it (and are competent...) it can be very easy to run circles around the standard library.