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.
ShroudedNight · 2h ago
This is highly reminiscent of work I was exposed to in grad school on recombining library versions from different binary distributions in an attempt to diversify the attack surface of a system, but at a much more granular level:
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.
sureglymop · 4h ago
When you write and compile code, there is a phase called "linking". For example, one could compile pieces of code and then link them together into one binary.
A common challenge is decompiling and reverse engineering a compiled program, e.g. a game. The author realized that it's an interesting approach to do a sort of reverse-linking (or I guess unlinking) process of a program into pieces and then focusing on reverse engineering or reimplementing those pieces instead of the whole.
When it comes to decompiling games, enthusiasts in that hobby want to be able to reproduce/obtain source code that compiles to exactly the same instructions as the original game. I think there is usually also a differentiation between instruction matching and byte for byte matching reproduction. But it definitely seems like a simpler and better approach to do this piece by piece and be able to test with each new piece of progress.
That's my layman understanding of it having only dabbled in decompiling stuff.
boricj · 3h ago
This is pretty much spot on.
The key insight of delinking is that object files are relocatable and the process of linking them together (laying their sections in memory, computing all the symbol addresses, applying all the relocations) removes that property. But by reversing this process (creating a symbol table, unapplying the relocations/resynthesizing relocation tables, slicing new sections), code and data can be made relocatable again.
Since properly delinked object files are relocatable, the linker can process them and stitch everything back together seamlessly, even if the pieces are moved around or no longer fit where they used to be (this makes for a particularly powerful form of binary patching, as constraints coming from the original program's memory map no longer apply). Alternatively, they can be fed to anything that can process object files, like a disassembler for example.
Of course, the real fun begins when you start reusing delinked object files to make new programs. I like to say that it breaks down the linear flow of toolchain from compilation to assembly to linking into a big ball of wibbly-wobbly, bitsy wimey stuff. Especially if you start cross-delinking to a different platform than the original pieces of the program came from.
krackers · 2h ago
I think this finally answers a question I've had since I started learning programming. All my life I've been told "you can't convert a shared library to a static library". When you try to probe for more details, all you get is some mumbling about how a shared library is already prelinked for mapping into memory so the relocation table is lost. When you press further about the precise information loss that prevents you from reconstructing it, you get the equivalent of "you just can't ok!".
That was never satisfying to me because recompilation (decompiling to source code or IR that can be recompiled for another platform) is an academic field of study [1], so the problem of converting a shared library to a static one should be easier. After all, you have all the assembly and symbol information right there, it seemed like all you needed to do was massage it the right way.
This comment has made my day in ways words cannot express.
But yeah, one recurring problem is that without literature on this esoteric and complex topic, any discussion remotely technical about it (especially without prior context) quickly bogs down, as it needs to be bootstrapped from first principles in order to make any sense.
I've been meaning to write the Necronomicon of delinking to at least be able to point people to a document that contains everything they need to know in order to understand or at least decently grasp this. At the very least it should make for a good horror bed time story for linker developers.
nyanpasu64 · 2h ago
What's "wrong" with matching decompilation as an oracle for provably correct source code for a given binary?
abetusk · 4h ago
Was this really a re-invention? Isn't this more akin to invention?
boricj · 3h ago
I did not actually invent delinking, there was some scant evidence of prior art online before I did my stuff. I did however come up with it independently from first principles.
As for the reinvention part, I was referencing the wheel of video game decompilation specifically. By that point Super Mario 64 was already fully decompiled and several other projects were well underway. The established wheel was matching decompilation (either instruction or byte level) and the community was producing tooling for this sole purpose.
In a sense, I did reinvent the wheel of video game decompilation in stark contrast to everything else that was out there at the time. It just turned out horribly right, because before I knew it I was making chimeras executables made out of bits of programs coming from different platforms.
babuloseo · 3h ago
Someone did something similar for the Davinci Resolve plugin, I think they have the crown for best VR addon atm.
I feel this article misses the main reason (unless it falls under "Build a better wheel") which is to build a wheel that is tailored and stays tailored to your purposes.
How often do I see people metaphorically trying to use a car tire on bicycle with thee excuse of not re-inventing the wheel. There can be great benefits for the parts of your system to be tailor made to work together.
drpixie · 34m ago
Absolutely - there are so many really bad wheels out there:
- wheels that force you to do things that way the maker wants, instead of the way that suits you;
- wheels that are fine going downhill ... but nowhere else;
- wheels require you to attach an ever more expensive widget;
- wheels that promise but never quite deliver;
- wheels that keep pushing you into services that you just know are going to be a pain.
Often your own wheel is the best.
caseyohara · 8m ago
One that I run into most often:
- A Formula 1 wheel when all you need is a bicycle wheel, but the person in charge of choosing wheels chooses it on the basis of “if we want to be as good as Formula 1, then we need to use the same wheels as Formula 1”
begueradj · 7h ago
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 · 7h 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.
zzo38computer · 6h 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.
jfengel · 6h 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.
rjsw · 5h ago
A ruby application that I will soon need to use downloads 227 packages.
jonny211 · 4h ago
That's wild. Which gem is it? Something AWS?
zoky · 2h ago
OP said that was for an entire app, not dependencies for a single gem. And it’s not really that many. A bone-stock Rails app includes almost 120 gems out of the box. Add a few additional gems that each have their own dependencies and you can get up to over 200 total packages pretty quick.
thfuran · 6h 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.
kortilla · 6h ago
That’s true for frameworks but not good libraries.
layer8 · 3h ago
Frameworks are clearly worse, that's true. But there are also kitchen-sink libraries that are too shallow in relation to their API surface, or libraries that perform certain background work or modify some external global state in a way that is unnecessary for your use case, or libraries that pull in transitive dependencies of that sort. You really want to minimize the code that executes in order to fulfill your use case, and also minimize the temptation to depend on additional, tangential functions of a library that you wouldn’t have added for those functions alone.
deadbabe · 2h ago
Actually, now that we have decent LLMs, rolling your own crypto is probably feasible.
bitwize · 5h 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 · 4h 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.
speed_spread · 4h ago
Getting the algorithm right is the easy part. It's the details of the implementation that kill you. Don't roll your own crypto.
ChrisMarshallNY · 2h ago
That's the main reason that I tend to "Reinvent the wheel."
Also, the dependencies often have a lot of extra "baggage," and I may only want a tiny bit of the functionality. Why should I use an 18-wheeler, when all I want to do, is drive to the corner store?
Also, and this is really all on me (it tends to be a bit of a minority stance, but it's mine), I tend to distrust opaque code.
If I do use a dependency, it's usually something that I could write, myself, if I wanted to devote the time, and something that I can audit, before integrating it.
I won't use opaque executables, unless I pay for it. If it's no-money-cost, I expect to be able to see the source.
efavdb · 4h ago
Another: getting good at invention / research is a skill that can be honed through practice - and you can practice on previously solved problems.
sroussey · 3h ago
Yeah, I built a library to run tasks based on a directed a-cyclical graph (DAG) and each task can optionally belong to a queue.
So I had to write a simple queue, but since I wanted demos to work in the browser it has a IndexedDB backend, and I wanted demos it to work in an Electron app, so there is a SQLite backend, and I’ll likely want a multi-user server based one so there is a Postgres backend.
And I wanted to use it for rate limiting, etc, so limiters were needed.
And then there is the graph stuff, and the task stuff.
There are a lot of wheels to-create actually, if you don’t want any dependencies.
I do have a branch that uses TypeBox to make and validate the input and output json schemas for the tasks, so may not be dependency free for the core eventually.
skinowski · 4h ago
+1, also sometimes to avoid complexity due to unnecessary abstractions/modularity, etc.
fnord77 · 30m ago
I was on a code review where someone imported an entire library just to use the library's Pair<> class, which Java does not have.
But it is literally a one liner to declare a Pair<> type in java
```
record Pair<S, T>(S first, T second) {}
```
sshine · 3h ago
Reinventing the wheel is the real deal.
anyonecancode · 5h ago
Less "reinventing" the wheel and more "uncovering the wheel."
megadragon9 · 7h 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.
epolanski · 5h 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.
throwaway173738 · 15m ago
The other 1% does it because the original wheel constrains them to an inferior approach that doesn’t work for their employer.
chad_c · 4h 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 your fencing was done by idiots, then at some point you have no alternative but to start tearing down fences and see what happens. Chesterton's Fence implies either a degree of design or a timeworn quality that most software products don't match.
Chesterton himself was using it as a religious metaphor, and I think most of us agree that software engineers are not literal gods.
dclowd9901 · 32m ago
It's funny. I had a similar analogy with some legacy systems recently. No one seemed to own or know where the data egressed to or whether it was even used anymore.
But it was also low-value data and even in the worst case we surmised the most we'd do is anger someone in marketing briefly.
I think so long as you can ascertain that the stakes are low, this is a good tactic.
chad_c · 1h ago
It’s not that you can’t tear down the fences. It’s that you studied why they were there in the first place.
rTX5CMRXIfFG · 4h 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.
bigstrat2003 · 3h ago
> It's not really the best way to learn because it's the most expensive and time-consuming.
The expense (time or otherwise) follows from how intimately you have to get to know the subject. Which is precisely why it's the best way to learn. It's not always viable, but when you can spare the expense nothing else compares.
grg0 · 4h ago
That sounds like learning something only very superficially. Rewriting from scratch is the only way to really learn any topic of non-trivial depth and complexity.
kupopuffs · 1h ago
depends on what you're optimizing for
dclowd9901 · 2h ago
> It usually comes from a good place, but is typically given by two groups of people:
> those who tried to invent a wheel themselves and know how hard it is
> those who never tried to invent a wheel and blindly follow the advice
There's a third, and I think more common group: folks who know all that's involved with reinventing the wheel, and how to do it, and know the juice of doing it isn't worth the squeeze, and there's no value in doing it yourself, educational or otherwise.
MetaMalone · 2h ago
This group is much more tangible for me. Instead of trusting the status quo, this group fears it.
mullingitover · 5h ago
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 · 5h 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 · 5h ago
I guess it's more like an advice for personal wheels, not professional ones.
gfalcao · 3h ago
Thanks for sharing that article.
A great friend of mine once told me the following quote from an unknown author: "Reinvent the wheel, not because we need more wheels but because we need more inventors."
That quote has brought my mind and heart to some modicum of tranquility at various occasions when I wanted to learn some concept and resolved to write my own "toy version" of a software library, framework et cetera.
Later on, when I learned about Feynman's quote “What I cannot create, I do not understand”, amalgamated the sentiment that it is okay to build something in order to learn one concept. I have thus far learned that in every new journey to reinvent the wheel, so to speak, often led me to paths where my intuitions about the initial concept got stronger and beyond that, I learned several other concepts.
hk1337 · 40m ago
I wouldn't say it's harmful advice but it is often over-used/abused to continue working on a lopsided wheel because, "if it ain't broke..."
ppqqrr · 4h 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 · 4h 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.
whstl · 3h ago
The problem is that I work at a wheel design factory and get paid for it, unlike the hobbyists who make 95% of the wheels on Github.
I'm all for reusing frameworks, standard libraries, crypto. Sure, those are things we don't want to recklessly reinvent.
I created a bike with one html and one css wheel to cycle through the wheel reinvention factories in my area and I can confirm that rabbit holes are a thing.
kayodelycaon · 4h 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.
semiinfinitely · 6h 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.
EasyMark · 10m ago
I've never encountered this person. Most people who say it, simply say it to save time and effort. I'm working on a product that allows my customer to do X job. I don't need to reinvent a json parsing library or sqlite-like database to get his site online and running his service, and he doesn't care that I didn't write those libraries. I don't feel guilty for skipping starting from zero. If I'm interested in a subject or algorithm then it makes complete sense to reinvent the wheel for my own personal advancement, knowledge, or amusement.
isaacremuant · 5h 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.
whstl · 3h ago
If it were my team complaining about "wheel reinvention" or "NIH" I would be ok, but I never saw this kind of gatekeeping at work.
It's always internet strangers who are too dogmatic even though there's zero context.
hn_go_brrrrr · 2h ago
I've encountered _plenty_ of stubborn dogmatism at work. People get an idea about "the right way" to do something, and refused to consider alternatives.
arionhardison · 1h ago
I'm recreating the "Gov" - not really; just my idea of it, globally e.g.: ua.gov-ai.co / ua.ai-gov.co/ ng.gov-ai.co / ng.ai-gov.co - most progress made so far w/ CBER and DDP's
* HHS -> FDA -> CBER
It's important IMO (IMO only NOT AN EXPERT) because it helps you understand first principles better. As fundamentals change, its helps me to reevaluate these things even though I know nothing will ever come of them.
I am 422 agencies in so far, hoping to finish in-time for Juneteenth. Cant post her because........... but yea.
Re-invent the wheel!
richardjennings · 7h 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."
fHr · 19m ago
cries in working with osgi garbage in 2025, I don't want to reinvent the wheel on that one I just hope that shit dies
zero-sharp · 7h 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.
pona-a · 3h ago
There are many, many "educators" that will tell you to not dare think about a wheel more than it takes to mount a new one in.
tehnub · 7h 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.
pcthrowaway · 1h ago
> Q: Will you mainline it?
> A: While I am a strong believer in the future of the rotary dial as an input
device, Linus Torvalds might disagree
Natsu · 18m ago
> In Computer Science, for example, there are many concepts that are commonly assumed to be beyond the abilities of mere mortals: protocols, cryptography, and web servers come to mind.
This baffles me, because a basic HTTP/1.0 server is about 20 lines of printing certain human-readable text over a socket in Perl, and I'm not cheating by just importing a library that does all the things.
I know because I have a www.pl script sitting around that I've frequently using for testing and such. I'm sure it violates various parts of the RFCs in different ways, but... sometimes that's what I'm testing anyway, and when I do want it to work, it simply prints file contents over a socket with a content-type header based on the file extension. It's even smart enough not to be vulnerable to directory traversal (i.e. it'll only serve files from the content directory), etc.
Sure, that's in some sense cheating by leaving out a lot of hard parts from HTTP/1.1 or 2.0, but really, you're just reading a string coming over a network socket, responding with another string, and then closing the connection with HTTP/1.0. You're really just worried about printing out the right thing in response to input from the client.
It's not magic and it's not even very complicated. At least crypto has a lot of formulas to keep track of, timing attacks to worry about, etc. You can have a simple web server that's too dumb to be vulnerable to most web attacks with a few lines of scripting, most of which involve formatting strings and printing them.
dustingetz · 4h ago
Time Is The Denominator,
especially in an industry context where you are being paid (there’s that pesky denominator again). R&D, which is what this is, is a very expensive and risky endeavor. 99% of startup projects fail, for example. They would not fail given infinite time, but you cant have that because time is not free:
Interest Is The Price Of Time
low_tech_punk · 7h 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.
whstl · 3h ago
The fearlessness of AI is indeed refreshing.
awinter-py · 6h 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
tough · 55m ago
Im reinventing wheels daily
KaiserPro · 1h ago
Re-invent the wheel all you like, just don't try that shit in production, unless you want to cause a delay.
Sometimes there are very good reasons to reinvent the wheel, where the buisness demands a faster x, or there are privacy concerns for y. But most of the time its just a bad idea to re-invent the wheel. Do that shit on your own time, and keep it out of our production codebase.
I know there will be lots of people moaning about curiosity and the like. I somewhat agree. However imagine you are building a new table. Nothing interesting just metal frame with a composite wooden top. You are prototyping is, and suddenly, one of your engineers decides to reinvent screws. Not because there is a need, but because they are bored.
Its not like you need hidden, or fancy screws/attachement devices, the engineer is just curious about trying out a lathe. Not that you have an "automatic" lathe, so it not like you can scale up production.
Its fucking stupid right? yes.
Sure, test out how to make your own fasteners. Even do it on company time. Just don't try and sneak it into production. Its a bad idea.
Ekaros · 7h 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 · 6h 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.
almosthere · 5h ago
People that work at Radial, Michelin, Good Year, etc... probably are sick of hearing it.
graypegg · 7h 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 · 6h ago
And the even more general advice: "First, break all the rules"
(not (necessarily) the book).
hoppp · 7h ago
You can reinvent the wheel for a specialized niche case but just dont expect many people to use it.
cryptonector · 2h ago
Yes, reinvent away, but first learn about what came before.
gblargg · 1h ago
I think you need to invent it first, so you have no pre-existing ideas. Then you get the "doing it my way" out of your system and come to understand the challenges. Then when you see how it's done, you can see the wisdom of experience. Where it seems like it's poorly done, if you study you can see benefits to that.
A huge benefit to not re-inventing is that standardization is a big value. Compare auto tires to phone batteries (back when they were replaceable). Auto tires are standardizes whereas every phone used its own slightly differently shaped battery.
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.
brightball · 3h ago
That’s how you get better wheels
OtomotO · 6h 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)
turtleyacht · 7h 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.
mcnamaratw · 7h 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 · 7h ago
"Sometimes it’s a good idea to reinvent the wheel" would have been a better title.
nssnsjsjsjs · 6h ago
Oh I totally assumed this applied to passion projects, making your own K8s on weekends kind of thing.
demirbey05 · 7h ago
If you invent someting better, you can get reward, lots of examples out there.
mcnamaratw · 7h ago
Sure. But inventing something better is not reinventing the wheel. Those are two completely different activities.
nssnsjsjsjs · 6h ago
It doesn't have to be not better though. The wheel reinventor has hindsight.
65 · 3h ago
When you rephrase it to "Make your own wheel" it sounds a lot more empowering.
Many of my side projects are just my own version of things that are specifically tailored to my preferences. I have a notes web app that backs up to S3. I have my own music streaming service. I have my own music discovery algorithm.
Sure these things exist, but because I made them, they do exactly what I want them to do. There is no one "wheel" - there are infinite permutations of what a "wheel" can be.
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.
Ekaros · 7h 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.
hoppp · 7h 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.
mcnamaratw · 7h ago
I’m sorry but you’re mistaken. The wheel was invented thousands of years ago.
iamwil · 4h ago
"Sometimes people reinvent the wheel not to get better wheels, but to get better inventors."
artursapek · 3h ago
This is so relevant to what I’m working on right now. Happy to see someone with this sentiment
basket_horse · 7h ago
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.
whstl · 3h ago
If "this will be properly maintained" was the bar for dependencies, hello world React projects would have a double-digits number of dependencies instead of 1484 [1].
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.
basket_horse · 2h ago
I don't disagree, and it really depends on the complexity of what you are trying to do. If it's a simple util function, it makes total sense. But for complicated solutions where open source alternatives already exist, its a hard argument to spend your time reinventing it unless just for learning purposes.
zzo38computer · 2h ago
> But for complicated solutions where open source alternatives already exist, its a hard argument to spend your time reinventing it unless just for learning purposes.
Even if the open source alternatives already exist, does not necessarily mean that they do what you want them to do. In some cases they can be fixed to do what you need (since it is open source, that is an advantage), but sometimes it cannot really be done without rewriting it and making a new one.
sfpotter · 6h ago
So many bitter and jaded people in this thread.
priorityfill · 6h 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).
whstl · 4h ago
> 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 · 2h ago
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.
Blikkentrekker · 7h 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 · 5h 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.
https://people.scs.carleton.ca/~soma/pubs/bfoster-gecco-2010...
A common challenge is decompiling and reverse engineering a compiled program, e.g. a game. The author realized that it's an interesting approach to do a sort of reverse-linking (or I guess unlinking) process of a program into pieces and then focusing on reverse engineering or reimplementing those pieces instead of the whole.
When it comes to decompiling games, enthusiasts in that hobby want to be able to reproduce/obtain source code that compiles to exactly the same instructions as the original game. I think there is usually also a differentiation between instruction matching and byte for byte matching reproduction. But it definitely seems like a simpler and better approach to do this piece by piece and be able to test with each new piece of progress.
That's my layman understanding of it having only dabbled in decompiling stuff.
The key insight of delinking is that object files are relocatable and the process of linking them together (laying their sections in memory, computing all the symbol addresses, applying all the relocations) removes that property. But by reversing this process (creating a symbol table, unapplying the relocations/resynthesizing relocation tables, slicing new sections), code and data can be made relocatable again.
Since properly delinked object files are relocatable, the linker can process them and stitch everything back together seamlessly, even if the pieces are moved around or no longer fit where they used to be (this makes for a particularly powerful form of binary patching, as constraints coming from the original program's memory map no longer apply). Alternatively, they can be fed to anything that can process object files, like a disassembler for example.
Of course, the real fun begins when you start reusing delinked object files to make new programs. I like to say that it breaks down the linear flow of toolchain from compilation to assembly to linking into a big ball of wibbly-wobbly, bitsy wimey stuff. Especially if you start cross-delinking to a different platform than the original pieces of the program came from.
That was never satisfying to me because recompilation (decompiling to source code or IR that can be recompiled for another platform) is an academic field of study [1], so the problem of converting a shared library to a static one should be easier. After all, you have all the assembly and symbol information right there, it seemed like all you needed to do was massage it the right way.
[1] https://rev.ng/
But yeah, one recurring problem is that without literature on this esoteric and complex topic, any discussion remotely technical about it (especially without prior context) quickly bogs down, as it needs to be bootstrapped from first principles in order to make any sense.
I've been meaning to write the Necronomicon of delinking to at least be able to point people to a document that contains everything they need to know in order to understand or at least decently grasp this. At the very least it should make for a good horror bed time story for linker developers.
As for the reinvention part, I was referencing the wheel of video game decompilation specifically. By that point Super Mario 64 was already fully decompiled and several other projects were well underway. The established wheel was matching decompilation (either instruction or byte level) and the community was producing tooling for this sole purpose.
In a sense, I did reinvent the wheel of video game decompilation in stark contrast to everything else that was out there at the time. It just turned out horribly right, because before I knew it I was making chimeras executables made out of bits of programs coming from different platforms.
No comments yet
How often do I see people metaphorically trying to use a car tire on bicycle with thee excuse of not re-inventing the wheel. There can be great benefits for the parts of your system to be tailor made to work together.
- wheels that force you to do things that way the maker wants, instead of the way that suits you;
- wheels that are fine going downhill ... but nowhere else;
- wheels require you to attach an ever more expensive widget;
- wheels that promise but never quite deliver;
- wheels that keep pushing you into services that you just know are going to be a pain.
Often your own wheel is the best.
- A Formula 1 wheel when all you need is a bicycle wheel, but the person in charge of choosing wheels chooses it on the basis of “if we want to be as good as Formula 1, then we need to use the same wheels as Formula 1”
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.
> 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.
Also, the dependencies often have a lot of extra "baggage," and I may only want a tiny bit of the functionality. Why should I use an 18-wheeler, when all I want to do, is drive to the corner store?
Also, and this is really all on me (it tends to be a bit of a minority stance, but it's mine), I tend to distrust opaque code.
If I do use a dependency, it's usually something that I could write, myself, if I wanted to devote the time, and something that I can audit, before integrating it.
I won't use opaque executables, unless I pay for it. If it's no-money-cost, I expect to be able to see the source.
So I had to write a simple queue, but since I wanted demos to work in the browser it has a IndexedDB backend, and I wanted demos it to work in an Electron app, so there is a SQLite backend, and I’ll likely want a multi-user server based one so there is a Postgres backend.
And I wanted to use it for rate limiting, etc, so limiters were needed.
And then there is the graph stuff, and the task stuff.
There are a lot of wheels to-create actually, if you don’t want any dependencies.
I do have a branch that uses TypeBox to make and validate the input and output json schemas for the tasks, so may not be dependency free for the core eventually.
But it is literally a one liner to declare a Pair<> type in java
``` record Pair<S, T>(S first, T second) {} ```
[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
Chesterton himself was using it as a religious metaphor, and I think most of us agree that software engineers are not literal gods.
But it was also low-value data and even in the worst case we surmised the most we'd do is anger someone in marketing briefly.
I think so long as you can ascertain that the stakes are low, this is a good tactic.
The expense (time or otherwise) follows from how intimately you have to get to know the subject. Which is precisely why it's the best way to learn. It's not always viable, but when you can spare the expense nothing else compares.
> those who tried to invent a wheel themselves and know how hard it is
> those who never tried to invent a wheel and blindly follow the advice
There's a third, and I think more common group: folks who know all that's involved with reinventing the wheel, and how to do it, and know the juice of doing it isn't worth the squeeze, and there's no value in doing it yourself, educational or otherwise.
A great friend of mine once told me the following quote from an unknown author: "Reinvent the wheel, not because we need more wheels but because we need more inventors." That quote has brought my mind and heart to some modicum of tranquility at various occasions when I wanted to learn some concept and resolved to write my own "toy version" of a software library, framework et cetera. Later on, when I learned about Feynman's quote “What I cannot create, I do not understand”, amalgamated the sentiment that it is okay to build something in order to learn one concept. I have thus far learned that in every new journey to reinvent the wheel, so to speak, often led me to paths where my intuitions about the initial concept got stronger and beyond that, I learned several other concepts.
I'm all for reusing frameworks, standard libraries, crypto. Sure, those are things we don't want to recklessly reinvent.
But there's a limit. There should be way more pushback against things like this: https://news.ycombinator.com/item?id=39019001
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.
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.
It's always internet strangers who are too dogmatic even though there's zero context.
* HHS -> FDA -> CBER
It's important IMO (IMO only NOT AN EXPERT) because it helps you understand first principles better. As fundamentals change, its helps me to reevaluate these things even though I know nothing will ever come of them.
I am 422 agencies in so far, hoping to finish in-time for Juneteenth. Cant post her because........... but yea.
Re-invent 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."
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.
> A: While I am a strong believer in the future of the rotary dial as an input device, Linus Torvalds might disagree
This baffles me, because a basic HTTP/1.0 server is about 20 lines of printing certain human-readable text over a socket in Perl, and I'm not cheating by just importing a library that does all the things.
I know because I have a www.pl script sitting around that I've frequently using for testing and such. I'm sure it violates various parts of the RFCs in different ways, but... sometimes that's what I'm testing anyway, and when I do want it to work, it simply prints file contents over a socket with a content-type header based on the file extension. It's even smart enough not to be vulnerable to directory traversal (i.e. it'll only serve files from the content directory), etc.
Sure, that's in some sense cheating by leaving out a lot of hard parts from HTTP/1.1 or 2.0, but really, you're just reading a string coming over a network socket, responding with another string, and then closing the connection with HTTP/1.0. You're really just worried about printing out the right thing in response to input from the client.
It's not magic and it's not even very complicated. At least crypto has a lot of formulas to keep track of, timing attacks to worry about, etc. You can have a simple web server that's too dumb to be vulnerable to most web attacks with a few lines of scripting, most of which involve formatting strings and printing them.
especially in an industry context where you are being paid (there’s that pesky denominator again). R&D, which is what this is, is a very expensive and risky endeavor. 99% of startup projects fail, for example. They would not fail given infinite time, but you cant have that because time is not free:
Interest Is The Price Of Time
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
Sometimes there are very good reasons to reinvent the wheel, where the buisness demands a faster x, or there are privacy concerns for y. But most of the time its just a bad idea to re-invent the wheel. Do that shit on your own time, and keep it out of our production codebase.
I know there will be lots of people moaning about curiosity and the like. I somewhat agree. However imagine you are building a new table. Nothing interesting just metal frame with a composite wooden top. You are prototyping is, and suddenly, one of your engineers decides to reinvent screws. Not because there is a need, but because they are bored.
Its not like you need hidden, or fancy screws/attachement devices, the engineer is just curious about trying out a lathe. Not that you have an "automatic" lathe, so it not like you can scale up production.
Its fucking stupid right? yes.
Sure, test out how to make your own fasteners. Even do it on company time. Just don't try and sneak it into production. Its a bad idea.
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.
A huge benefit to not re-inventing is that standardization is a big value. Compare auto tires to phone batteries (back when they were replaceable). Auto tires are standardizes whereas every phone used its own slightly differently shaped battery.
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.
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)
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.
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.
Many of my side projects are just my own version of things that are specifically tailored to my preferences. I have a notes web app that backs up to S3. I have my own music streaming service. I have my own music discovery algorithm.
Sure these things exist, but because I made them, they do exactly what I want them to do. There is no one "wheel" - there are infinite permutations of what a "wheel" can be.
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.
[1] https://news.ycombinator.com/item?id=39019001
>3 million weekly downloads
Dear God.
Even if the open source alternatives already exist, does not necessarily mean that they do what you want them to do. In some cases they can be fixed to do what you need (since it is open source, that is an advantage), but sometimes it cannot really be done without rewriting it and making a new one.
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.
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.