9 ms·

Reinvent the Wheel

612 points by zdw 1y ago

tjpnz 1y ago
Was a post here recently about someone who did just this and was able to survive in a competitive niche. The key(?) is to look for those where a significant slice is owned by PE firms.
brightball 1y ago
That’s how you get better wheels
moron4hire 1y 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.
- mcnamaratw 1y ago
  I’m sorry but you’re mistaken. The wheel was invented thousands of years ago.
- hoppp 1y 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 1y 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 1y ago
You can reinvent the wheel for a specialized niche case but just dont expect many people to use it.
mcnamaratw 1y 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.
- demirbey05 1y ago
  If you invent someting better, you can get reward, lots of examples out there.
  - mcnamaratw 1y ago
    Sure. But inventing something better is not reinventing the wheel. Those are two completely different activities.
    - nssnsjsjsjs 1y ago
      It doesn't have to be not better though. The wheel reinventor has hindsight.
- baxtr 1y ago
  "Sometimes it’s a good idea to reinvent the wheel" would have been a better title.
- nssnsjsjsjs 1y ago
  Oh I totally assumed this applied to passion projects, making your own K8s on weekends kind of thing.
wcfrobert 1y ago
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 1y 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 1y ago
    I’m reminded of Chesterton’s Fence [1]. I just explained this to a coworker that was proud of indiscriminately eliminating 200+ positions. [1] https://www.lesswrong.com/w/chesterton-s-fence https://www.lesswrong.com/w/chesterton-s-fence
    - strken 1y ago
      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.
      - chad_c 1y 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.
        strken 1y ago
        Sometimes the reason a fence exists is because the person who put it there was some combination of a) an idiot, b) extremely confused, or c) not qualified to construct fences. Also, in software, you may find the fence sometimes exists in higher dimensions than the usual three, can turn invisible for part of its length, and occasionally exists but is four inches tall and blocks only mice. And it may also be designed, at least in part, by a blind idiot god called ChatGPT on whose altar consciousness itself is sacrificed. At this point it's worth considering whether keeping the fence around is worse than letting the bull out.
zero-sharp 1y 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 1y 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.
- pona-a 1y 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.
begueradj 1y 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 1y 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.
  - kortilla 1y ago
    That’s true for frameworks but not good libraries.
    - layer8 1y 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.
  - zzo38computer 1y 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.
turtleyacht 1y 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.
low_tech_punk 1y 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 1y ago
  The fearlessness of AI is indeed refreshing.
Blikkentrekker 1y 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 1y 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.
graypegg 1y 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.
Ekaros 1y 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 1y 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.
basket_horse 1y 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.
- jspdown 1y 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.
  - basket_horse 1y 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 1y 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.
    - jspdown 1y ago
      Yes exactly, each situation is different. As a team you constantly need to assess whether a dependency should be brought in or of a re-implementation is not better. Sometimes, the re-implementation is so specific to you actual problem that maintenance becomes almost free. A generic solution always open more doors to problems and require more effort to maintain. For a rich client web application, you need a really good reason not to bring an external dependency such as React.
megadragon9 1y 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 :) [1] https://github.com/workofart/ml-by-hand https://github.com/workofart/ml-by-hand [2] https://github.com/workofart/ml-by-hand/blob/main/examples/cnn.py https://github.com/workofart/ml-by-hand/blob/main/examples/c... [3] https://github.com/workofart/ml-by-hand/blob/main/examples/gpt2.py https://github.com/workofart/ml-by-hand/blob/main/examples/g...
richardjennings 1y 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."
xipho 1y ago
Previously at HN https://news.ycombinator.com/item?id=43434730 https://news.ycombinator.com/item?id=43434730
priorityfill 1y 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 1y 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 1y 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.
awinter-py 1y 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
boricj 1y ago
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.
- nssnsjsjsjs 1y ago
  I'll bite! What wheel is this?
  - Archelaos 1y ago
    Probably what he links to on his profile page.
  - weaksauce 1y ago
    got to imagine it is this https://github.com/boricj/ghidra-delinker-extension https://github.com/boricj/ghidra-delinker-extension
  - boricj 1y ago
    This wheel: https://github.com/boricj/ghidra-delinker-extension https://github.com/boricj/ghidra-delinker-extension 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.
OtomotO 1y 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)
incognito124 1y ago
closely related: https://news.ycombinator.com/item?id=43434730 https://news.ycombinator.com/item?id=43434730
random3 1y ago
And the even more general advice: "First, break all the rules" (not (necessarily) the book).
sfpotter 1y ago
So many bitter and jaded people in this thread.
- tomhow 1y ago
  Please don't fulminate. Please don't sneer, including at the rest of the community. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - sfpotter 1y ago
    Said with sadness, not sneeringly.
    - tomhow 1y ago
      Can you link to any of the comments that make you feel this way? I don't see it.
semiinfinitely 1y 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 1y 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 1y 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 1y 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.
      - whstl 1y ago
        I have also encountered plenty of stubborn dogmatism at work, but not this type as much. People might add a redundant or dangerous library because they don’t know better but they don’t fight for it, like here.
- EasyMark 1y ago
mullingitover 1y 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 1y 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 1y ago
  I guess it's more like an advice for personal wheels, not professional ones.
- lelanthran 1y ago
  If you're in a startup and you aren't reinventing some particular wheel, where exactly is your value proposition?
  - mullingitover 1y ago
    That's why I added the clause: > unless the particular wheel you're reinventing is core to the product/service your startup makes If it's core to your product/service, absolutely reinvent the hell out of that wheel. That's your business. Put pneumatic spokes on it. Add a touchscreen. Embed a bespoke LLM. Go nuts. Just stay focused on your customers. Don't do a bunch of things that are frankly just resume builders for your senior engineers and don't add value for your customers.
- yxhuvud 1y ago
  You are complaining about a symptom of not having enough experienced people onboard. Juniors will make a mess, regardless of if they try to use something existing or reinvent the wheel. Knowing when and what to reinvent is just a function of having worked at more places and for long enough to see what is good and bad with the existing solutions.
Waterluvian 1y 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.
almosthere 1y ago
People that work at Radial, Michelin, Good Year, etc... probably are sick of hearing it.
ppqqrr 1y 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 1y 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 1y 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. But there's a limit. There should be way more pushback against things like this: https://news.ycombinator.com/item?id=39019001 https://news.ycombinator.com/item?id=39019001
kayodelycaon 1y 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.
dustingetz 1y 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
deleted 1y ago
[deleted]
iamwil 1y ago
"Sometimes people reinvent the wheel not to get better wheels, but to get better inventors."
merillecuz56 1y ago
[dead]
gfalcao 1y 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.
artursapek 1y ago
This is so relevant to what I’m working on right now. Happy to see someone with this sentiment
65 1y 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.
cryptonector 1y ago
Yes, reinvent away, but first learn about what came before.
- gblargg 1y 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.
dclowd9901 1y 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 1y ago
  This group is much more tangible for me. Instead of trusting the status quo, this group fears it.
- 59nadir 1y ago
  > 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. I think this view of things is usually related to the fact that large parts of this group are simply too bad at reinventing wheels and in large part are gun-shy because of previously failed attempts at doing a good job. One of my former leads had worked for 7+ years in the same company by the time I showed up and he was absolutely useless as a programmer beyond just gluing together libraries because that's all he had ever done. He barely also knew the platform we ran on because he simply had developed no skill when it came to understanding things. For him and people like him reinventing wheels is simply not worth the time and since they're so bad at it and always fail they'll never actually learn anything. I heard from him last year (7 years after we both left the company we worked together at) and he still only glues libraries together, but he does it in Rust instead of Erlang nowadays.
BenoitEssiambre 1y ago
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 1y 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 1y 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”
    - skydhash 1y ago
      It's worse when they bring parts of the car still attached to that wheel and wants you to fit all of it to the bicycle.
KaiserPro 1y 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.
pcthrowaway 1y 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
arionhardison 1y 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!
tough 1y ago
Im reinventing wheels daily
aaron695 1y ago
[dead]
mediumsmart 1y ago
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.
hk1337 1y 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..."
fHr 1y 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
Natsu 1y 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.
- immibis 1y ago
  FWIW you're also allowed to close the connection in 1.1, but you have to send a header saying you're doing so. You also don't have to, as it's not that hard to allow pipelining.
  - Natsu 1y ago
    Sure, you can just send Connection: close but that's not generally what people want, because they might have take a hit to latency by establishing another SSL connection.
osigurdson 1y ago
What is the logical overlap between "re-invent" and "improve". When people say "don't re-invent the wheel" do they really mean "don't improve the wheel"? This seems unlikely to me. Of course, the "3000 BCE" retort is a good one and I hope to use it at least once in my lifetime.
90s_dev 1y ago
These points summarize the principles behind 90s.dev which I've been following for years and still stand by. Especially this: don't be afraid to try to innovate, to get a new answer to an old question, to start over from first principles, even if it fails. Because it might not.
eviks 1y ago
None of these require reinvention > There are great reasons to reinvent the wheel: > Build a better wheel (for some definition of better) You can invent an improvement, no need to reinvent the existing wheel > Learn how wheels are made Read a book > Teach others about wheels Read a book and tell others about it > Learn about the inventors of wheels Read a history book > Be able to change wheels or fix them when they break Read an engineering manual etc.
- hahn-kev 1y ago
  Reading is not the same as experience gained through doing
  - eviks 1y ago
    So how would that different experience in any way help you learn about the inventors of wheels?
- engeljohnb 1y ago
  I would never listen to the advice of someone that said they read a book or a manual about [whatever project I'm working on] but never actually attempted one themselves.
  - eviks 1y ago
    That's fine, this is neither about your project nor giving advice to you
PeterStuer 1y ago
We all work on mental models of the things we use, envision or encounter. I've often found that it was not until I tried to build that model for real that I had missed significant crucial parts, not just a matter of 'incompleteness' or a too high level abstraction, but that my model no matter how elegant was just wrong or unworkable.
zmmmmm 1y ago
I think the article subtley misinterprets the whole idea of it and the problem of it. It's fine to invent your own wheel. But that doesn't mean you should put it in production or feel any entitlement for anybody else to use it there, just because you put personal effort into it. It's going to need to be at least as good, if not better, not just in whatever novel genius way you made it unique, but in all the boring ways - testing, documentation, supportability, etc.
- jonahx 1y ago
  This is a good point, but there is a countervailing one: Sometimes the already invented, tested, and documented "standard" thing is much bigger than what you need. Perhaps you need one feature out of ten. It can make sense to re-invent the wheel to make exactly what you need, and nothing more, even at the expenses you've mentioned. Not always -- you need to weigh all the factors for your own situation -- but choosing "re-invention" is not necessarily a merely-indulgent exercise of ego.
  - augusto-moura 1y ago
    Sometimes the size doesn't really matter, maybe if you are working on a constrained space (embedded software, let's say). But if you are doing Web or using any modern language, unused code is usually optimized out of the compiled bundle and you don't care about it. We care much more about tested and battle proven behavior
    - jonahx 1y ago
      I am talking about size of cognitive load, complexity, attack surface area, etc.
tylervigen 1y ago
I learned a fun fact this year that completely changed how I think about wheels. Ancient wheels supported weight through compression: the cart pressed down, the wheel transferred that force straight into the ground. Simple and solid. Modern wheels? Totally different. Bicycle wheels hold weight through tension. If a bike is standing still, you could cut the bottom spokes and it would stay upright. Cut the top ones and it collapses—the rim is literally hanging from the hub. Even car tires follow this principle. It’s not just a balloon of air under the wheel. The internal pressure forms a tensioned ring that holds the car up. The car is suspended from the tire, not resting on it. So while the article encourages reinventing the wheel metaphorically, I can’t help but admire how we’ve already reinvented the wheel literally—by flipping the physics entirely. If you're visual like me, this video illustrates it perfectly: https://youtu.be/8I7QsgYm_NU?si=Vz1aqpHBAPjayqlG https://youtu.be/8I7QsgYm_NU?si=Vz1aqpHBAPjayqlG
- thunderbong 1y ago
  That was very interesting. I had never thought about this earlier. I learned something new today! Thanks.
- astrobe_ 1y ago
  Yes, as TFA alludes to, this expression is actually a bit wrong because the wheel has often been reinvented since ~4500 BCE. The latest "reinventions" are as recent as 19-20th century with the continuous track, monowheel, "hubless" wheel and mecanum wheel [1] [2]. [1] https://en.wikipedia.org/wiki/Hubless_wheel https://en.wikipedia.org/wiki/Hubless_wheel [2] https://en.wikipedia.org/wiki/Mecanum_wheel https://en.wikipedia.org/wiki/Mecanum_wheel
  - moron4hire 1y ago
    It seems to me that most people say, "don't reinvent..." because they believe there is an existing, ubiquitous, sufficient solution (well, that's why they think it. Why they say it out loud as a response to someone's project, I have different theories on that). But in ubiquitous solutions, we also find assumptions and trade-offs that require constraining the application to fit the solution. Thus it is there, in those assumptions and trade-offs, as these literal wheel examples demonstrate, where we find the ability to usefully reinvent. I have to laugh a little seeing your reference to Mecanum wheels and your post being dated 6 hours ago. 12 hours ago, I rewatched the Star Trek reboot film. In it, there is a scene where the characters are all loading into shuttles to head off to their assignments. In the background, we are supposed to be impressed with the technical advancement of the machinery in view, e.g. how something as familiar as a forklift has "futuristic" details like strange wheels. And those wheels on that forklift are Mecanum wheels. In-story, that makes them something like ~300 year old technology.
fizlebit 1y ago
People say don't reinvent the wheel usually in a business context because writing from scratch is usually a lot more work than using existing technologies. Sure reusing technologies is also a lot more work than you would expect because most things suck (to different degrees), but so will your newly minted wheel. Only after a lot of hard lessons will it suck less, if at all. That said there are also contexts in which the existing system that was built sucks so bad that rewriting it usually a boon, even if the new wheel sucks, it sucks less from the start. You at a minimum should engage with the existing wheels and their users to find the ways in which they do and don't work. In your own time I think it is great to tinker, pull apart, assemble your own things. Every Jedi makes her own light saber right?
- Derbasti 1y ago
  Especially at work, I find existing solutions often lacking. We tend to overestimate the complexity of reinventing many things, and underestimate the cost of ill-fitting abstractions. In particular, Google-scale frameworks are usually harmfully over-engineered for smaller companies. Their challenge is solving the Google scale, not the problem at hand. At the same time, their complexity implies that a small-scale solution will likewise require a hundred-programmer team to implement. But I find that far from the truth. In fact, many problems benefit from a purpose-built, small-scale solution. I've seen this work out many times, and result in much simpler, easier-to-debug code. Google-scale frameworks are a very bad proxy for estimating the complexity of a task.
- pzo 1y ago
  This. Reinventing the wheel in business context IMOH should be only if: - you can afford it (money) - you have enough time or your customer can wait - provide significant benefit to you or your customers (have nothing better to do) - you don't have fierce competition in your domain - you are pretty much retired (or could) and treating it more like art/craft/passion project I compare it with building some custom made designer house and furniture. Many would want that, only some can afford it, even less will pay for it.
Zk_one 1y ago
[dead]
lukaslalinsky 1y ago
When you have a niche problem, you can usually reduce it in scope to such level, that you can make significantly better solution than trying to adapt some existing technology. It's not going to be universal, but for your niche problem, it can be much more suited. Back in 2010, I started an open source project for identifying audio files based on fingerprints. I specifically designed everything, so that in the end I need to do super fast i32->i32 lookups on scale. There were many inverted indexes, but they are usually for text search, which has a lot of overhead I don't need. I ended up writing a completely custom solution, and it allowed me to scale to millions and millions of fingerprints on such small servers that it was unimaginable to anyone who ever ran audio fingerprinting system before.
sireat 1y ago
As you get older, you have to become much pickier which if any wheels to reinvent. As others said reinventing the wheel is fantastic for learning, but not so for production / real life stuff. So for example implementing your own transformers from scratch - great for learning but for 99% it would not meaningfully change how you use LLMs for mundane things. So only when the domain is really really meaningful to you, you could consider reinventing the wheel and even then do not expect any immediately payoffs. Those 4000 weeks pass by awfully quickly. You have to pick your battles / wheels.
jaza 1y ago
Valid points in the article and in many of the comments here. BUT: taken to the extreme, "yes, reinvent the wheel!" quickly becomes NIH ("not invented here") syndrome, which I've seen one too many times in enterprise stacks, as I'm sure plenty of you folks have too. We don't need no stinkin' wheels from the OUTSIDE! I think every codebase needs a healthy and pragmatic balance of "this particular wheel we can and should build ourselves, and it'll work better (for us at least!) than any other wheels out there" vs "there is a standard wheel for this, 10 million other horse-and-carriages out there use the same wheel, it's not worth us using a non-standard wheel for this thing".
sylware 1y ago
It is interesting to do it, if it significantly simplifies and goes better to the point. Often, it is to give a variant proposal to something, rarely a bad thing. For, instance in software, alternative implementations are somewhat critical. It is actually a necessity "in the current economy" in order to sanely "work".
bullen 1y ago
When people say "don't reinvent the wheel" they really mean to say "don't copy the wheel". Reinvent means changing something, hopefully for the better: http://move.rupy.se/file/wheel.jpg http://move.rupy.se/file/wheel.jpg
kovac 1y ago
In the context of software, I wonder what would qualify as a wheel. I'd say implementations of standards like protocols, BLAS, etc probabaly are wheels and not trivial to reinvent. Would you consider something like Kubernetes, Docker, web browsers, web frameworks as wheels? I can't help but think the software quality would be much higher if the latter set wasn't considered as wheels and we tried to reinvent them often.
roes9627 1y ago
well i don't disagree so long as you have the time and your manager isn't rushing you to deploy that feature "ASAP" ;)
SwtCyber 1y ago
Sometimes the value isn't in creating something new for the world, it's in creating something new for yourself... I like it
tobr 1y ago
”Reinventing the wheel” is a misguided idea in the first place, because the invention of the wheel was really the invention of the road. So, it’s a phrase that in more ways than one suggest that you have no idea what invention is about.
didgetmaster 1y ago
Much of the bloated and inefficient code out there is the result of simply pulling something off the shelf and using it, just because it 'kind of' does what you need. Nevermind that a much simpler and efficient piece is possible, we have to ship ASAP so don't bother to spend any time on it. Include a whole set of dependencies just because we need a function or two in a huge library or framework. Worry about optimizations later (i.e. never).
ernestohegi 1y ago
How do you explain this to product owners in economic terms?
newExampleUser 1y ago
[flagged]
tiou 1y ago
In deep learning, gradient descent often gets stuck in local optima. While these points may not be perfect, they represent workable solutions given the current landscape. Similarly, existing “wheels” in software development are like these local optima—well-established solutions that work well in many cases but might not fit every unique scenario. Reinventing the wheel can be seen as an attempt to escape these local optima, exploring new approaches that better suit specific needs or constraints. This process involves effort and risk, just like tweaking optimization parameters in training, but it can lead to innovative and more tailored solutions. So, rather than blindly accepting existing solutions, sometimes it’s worth challenging them and trying to find a different path—just as in deep learning, where escaping local optima can improve model performance.
mppm 1y ago
> Note: When I say “wheel” throughout this post, please replace it with whatever tool, protocol, service, technology, or other invention you’re personally interested in. How did we sink this low?

612 points by zdw 1y ago

Was a post here recently about someone who did just this and was able to survive in a competitive niche. The key(?) is to look for those where a significant slice is owned by PE firms.

brightball 1y ago

That’s how you get better wheels

moron4hire 1y 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.

mcnamaratw 1y ago
I’m sorry but you’re mistaken. The wheel was invented thousands of years ago.
hoppp 1y 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 1y 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 1y ago

You can reinvent the wheel for a specialized niche case but just dont expect many people to use it.

mcnamaratw 1y 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.

demirbey05 1y ago
If you invent someting better, you can get reward, lots of examples out there.
- mcnamaratw 1y ago
  Sure. But inventing something better is not reinventing the wheel. Those are two completely different activities.
  - nssnsjsjsjs 1y ago
    It doesn't have to be not better though. The wheel reinventor has hindsight.
baxtr 1y ago
"Sometimes it’s a good idea to reinvent the wheel" would have been a better title.
nssnsjsjsjs 1y ago
Oh I totally assumed this applied to passion projects, making your own K8s on weekends kind of thing.

wcfrobert 1y ago

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 1y 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 1y ago
  I’m reminded of Chesterton’s Fence [1]. I just explained this to a coworker that was proud of indiscriminately eliminating 200+ positions. [1] https://www.lesswrong.com/w/chesterton-s-fence https://www.lesswrong.com/w/chesterton-s-fence
  - strken 1y ago
    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.
    - chad_c 1y 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.
      - strken 1y ago
        Sometimes the reason a fence exists is because the person who put it there was some combination of a) an idiot, b) extremely confused, or c) not qualified to construct fences. Also, in software, you may find the fence sometimes exists in higher dimensions than the usual three, can turn invisible for part of its length, and occasionally exists but is four inches tall and blocks only mice. And it may also be designed, at least in part, by a blind idiot god called ChatGPT on whose altar consciousness itself is sacrificed. At this point it's worth considering whether keeping the fence around is worse than letting the bull out.

zero-sharp 1y 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 1y 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.
pona-a 1y 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.

begueradj 1y 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 1y 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.
- kortilla 1y ago
  That’s true for frameworks but not good libraries.
  - layer8 1y 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.
- zzo38computer 1y 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.

turtleyacht 1y 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.

low_tech_punk 1y 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 1y ago
The fearlessness of AI is indeed refreshing.

Blikkentrekker 1y 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 1y 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.

graypegg 1y 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.

Ekaros 1y 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 1y 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.

basket_horse 1y 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.

jspdown 1y 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.
- basket_horse 1y 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 1y 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.
  - jspdown 1y ago
    Yes exactly, each situation is different. As a team you constantly need to assess whether a dependency should be brought in or of a re-implementation is not better. Sometimes, the re-implementation is so specific to you actual problem that maintenance becomes almost free. A generic solution always open more doors to problems and require more effort to maintain. For a rich client web application, you need a really good reason not to bring an external dependency such as React.

megadragon9 1y 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 :) [1] https://github.com/workofart/ml-by-hand https://github.com/workofart/ml-by-hand [2] https://github.com/workofart/ml-by-hand/blob/main/examples/cnn.py https://github.com/workofart/ml-by-hand/blob/main/examples/c... [3] https://github.com/workofart/ml-by-hand/blob/main/examples/gpt2.py https://github.com/workofart/ml-by-hand/blob/main/examples/g...

richardjennings 1y 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."

xipho 1y ago

Previously at HN https://news.ycombinator.com/item?id=43434730 https://news.ycombinator.com/item?id=43434730

priorityfill 1y 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 1y 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 1y 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.

awinter-py 1y 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

boricj 1y ago

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.

nssnsjsjsjs 1y ago
I'll bite! What wheel is this?
- Archelaos 1y ago
  Probably what he links to on his profile page.
- weaksauce 1y ago
  got to imagine it is this https://github.com/boricj/ghidra-delinker-extension https://github.com/boricj/ghidra-delinker-extension
- boricj 1y ago
  This wheel: https://github.com/boricj/ghidra-delinker-extension https://github.com/boricj/ghidra-delinker-extension 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.

OtomotO 1y 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)

incognito124 1y ago

closely related: https://news.ycombinator.com/item?id=43434730 https://news.ycombinator.com/item?id=43434730

random3 1y ago

And the even more general advice: "First, break all the rules" (not (necessarily) the book).

sfpotter 1y ago

So many bitter and jaded people in this thread.

tomhow 1y ago
Please don't fulminate. Please don't sneer, including at the rest of the community. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- sfpotter 1y ago
  Said with sadness, not sneeringly.
  - tomhow 1y ago
    Can you link to any of the comments that make you feel this way? I don't see it.

semiinfinitely 1y 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 1y 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 1y 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 1y 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.
    - whstl 1y ago
      I have also encountered plenty of stubborn dogmatism at work, but not this type as much. People might add a redundant or dangerous library because they don’t know better but they don’t fight for it, like here.
EasyMark 1y ago

mullingitover 1y 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 1y 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 1y ago
I guess it's more like an advice for personal wheels, not professional ones.
lelanthran 1y ago
If you're in a startup and you aren't reinventing some particular wheel, where exactly is your value proposition?
- mullingitover 1y ago
  That's why I added the clause: > unless the particular wheel you're reinventing is core to the product/service your startup makes If it's core to your product/service, absolutely reinvent the hell out of that wheel. That's your business. Put pneumatic spokes on it. Add a touchscreen. Embed a bespoke LLM. Go nuts. Just stay focused on your customers. Don't do a bunch of things that are frankly just resume builders for your senior engineers and don't add value for your customers.
yxhuvud 1y ago
You are complaining about a symptom of not having enough experienced people onboard. Juniors will make a mess, regardless of if they try to use something existing or reinvent the wheel. Knowing when and what to reinvent is just a function of having worked at more places and for long enough to see what is good and bad with the existing solutions.

Waterluvian 1y 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.

almosthere 1y ago

People that work at Radial, Michelin, Good Year, etc... probably are sick of hearing it.

ppqqrr 1y 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 1y 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 1y 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. But there's a limit. There should be way more pushback against things like this: https://news.ycombinator.com/item?id=39019001 https://news.ycombinator.com/item?id=39019001

kayodelycaon 1y 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.

dustingetz 1y 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

deleted 1y ago

[deleted]

iamwil 1y ago

"Sometimes people reinvent the wheel not to get better wheels, but to get better inventors."

merillecuz56 1y ago

[dead]

gfalcao 1y 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.

artursapek 1y ago

This is so relevant to what I’m working on right now. Happy to see someone with this sentiment

65 1y 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.

cryptonector 1y ago

Yes, reinvent away, but first learn about what came before.

gblargg 1y 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.

dclowd9901 1y 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 1y ago
This group is much more tangible for me. Instead of trusting the status quo, this group fears it.
59nadir 1y ago
> 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. I think this view of things is usually related to the fact that large parts of this group are simply too bad at reinventing wheels and in large part are gun-shy because of previously failed attempts at doing a good job. One of my former leads had worked for 7+ years in the same company by the time I showed up and he was absolutely useless as a programmer beyond just gluing together libraries because that's all he had ever done. He barely also knew the platform we ran on because he simply had developed no skill when it came to understanding things. For him and people like him reinventing wheels is simply not worth the time and since they're so bad at it and always fail they'll never actually learn anything. I heard from him last year (7 years after we both left the company we worked together at) and he still only glues libraries together, but he does it in Rust instead of Erlang nowadays.

BenoitEssiambre 1y ago

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 1y 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 1y 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”
  - skydhash 1y ago
    It's worse when they bring parts of the car still attached to that wheel and wants you to fit all of it to the bicycle.

KaiserPro 1y 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.

pcthrowaway 1y 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

arionhardison 1y 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!

tough 1y ago

Im reinventing wheels daily

aaron695 1y ago

[dead]

mediumsmart 1y ago

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.

hk1337 1y 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..."

fHr 1y 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

Natsu 1y 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.

immibis 1y ago
FWIW you're also allowed to close the connection in 1.1, but you have to send a header saying you're doing so. You also don't have to, as it's not that hard to allow pipelining.
- Natsu 1y ago
  Sure, you can just send Connection: close but that's not generally what people want, because they might have take a hit to latency by establishing another SSL connection.

osigurdson 1y ago

What is the logical overlap between "re-invent" and "improve". When people say "don't re-invent the wheel" do they really mean "don't improve the wheel"? This seems unlikely to me. Of course, the "3000 BCE" retort is a good one and I hope to use it at least once in my lifetime.

90s_dev 1y ago

These points summarize the principles behind 90s.dev which I've been following for years and still stand by. Especially this: don't be afraid to try to innovate, to get a new answer to an old question, to start over from first principles, even if it fails. Because it might not.

eviks 1y ago

None of these require reinvention > There are great reasons to reinvent the wheel: > Build a better wheel (for some definition of better) You can invent an improvement, no need to reinvent the existing wheel > Learn how wheels are made Read a book > Teach others about wheels Read a book and tell others about it > Learn about the inventors of wheels Read a history book > Be able to change wheels or fix them when they break Read an engineering manual etc.

hahn-kev 1y ago
Reading is not the same as experience gained through doing
- eviks 1y ago
  So how would that different experience in any way help you learn about the inventors of wheels?
engeljohnb 1y ago
I would never listen to the advice of someone that said they read a book or a manual about [whatever project I'm working on] but never actually attempted one themselves.
- eviks 1y ago
  That's fine, this is neither about your project nor giving advice to you

PeterStuer 1y ago

We all work on mental models of the things we use, envision or encounter. I've often found that it was not until I tried to build that model for real that I had missed significant crucial parts, not just a matter of 'incompleteness' or a too high level abstraction, but that my model no matter how elegant was just wrong or unworkable.

zmmmmm 1y ago

I think the article subtley misinterprets the whole idea of it and the problem of it. It's fine to invent your own wheel. But that doesn't mean you should put it in production or feel any entitlement for anybody else to use it there, just because you put personal effort into it. It's going to need to be at least as good, if not better, not just in whatever novel genius way you made it unique, but in all the boring ways - testing, documentation, supportability, etc.

jonahx 1y ago
This is a good point, but there is a countervailing one: Sometimes the already invented, tested, and documented "standard" thing is much bigger than what you need. Perhaps you need one feature out of ten. It can make sense to re-invent the wheel to make exactly what you need, and nothing more, even at the expenses you've mentioned. Not always -- you need to weigh all the factors for your own situation -- but choosing "re-invention" is not necessarily a merely-indulgent exercise of ego.
- augusto-moura 1y ago
  Sometimes the size doesn't really matter, maybe if you are working on a constrained space (embedded software, let's say). But if you are doing Web or using any modern language, unused code is usually optimized out of the compiled bundle and you don't care about it. We care much more about tested and battle proven behavior
  - jonahx 1y ago
    I am talking about size of cognitive load, complexity, attack surface area, etc.

tylervigen 1y ago

I learned a fun fact this year that completely changed how I think about wheels. Ancient wheels supported weight through compression: the cart pressed down, the wheel transferred that force straight into the ground. Simple and solid. Modern wheels? Totally different. Bicycle wheels hold weight through tension. If a bike is standing still, you could cut the bottom spokes and it would stay upright. Cut the top ones and it collapses—the rim is literally hanging from the hub. Even car tires follow this principle. It’s not just a balloon of air under the wheel. The internal pressure forms a tensioned ring that holds the car up. The car is suspended from the tire, not resting on it. So while the article encourages reinventing the wheel metaphorically, I can’t help but admire how we’ve already reinvented the wheel literally—by flipping the physics entirely. If you're visual like me, this video illustrates it perfectly: https://youtu.be/8I7QsgYm_NU?si=Vz1aqpHBAPjayqlG https://youtu.be/8I7QsgYm_NU?si=Vz1aqpHBAPjayqlG

thunderbong 1y ago
That was very interesting. I had never thought about this earlier. I learned something new today! Thanks.
astrobe_ 1y ago
Yes, as TFA alludes to, this expression is actually a bit wrong because the wheel has often been reinvented since ~4500 BCE. The latest "reinventions" are as recent as 19-20th century with the continuous track, monowheel, "hubless" wheel and mecanum wheel [1] [2]. [1] https://en.wikipedia.org/wiki/Hubless_wheel https://en.wikipedia.org/wiki/Hubless_wheel [2] https://en.wikipedia.org/wiki/Mecanum_wheel https://en.wikipedia.org/wiki/Mecanum_wheel
- moron4hire 1y ago
  It seems to me that most people say, "don't reinvent..." because they believe there is an existing, ubiquitous, sufficient solution (well, that's why they think it. Why they say it out loud as a response to someone's project, I have different theories on that). But in ubiquitous solutions, we also find assumptions and trade-offs that require constraining the application to fit the solution. Thus it is there, in those assumptions and trade-offs, as these literal wheel examples demonstrate, where we find the ability to usefully reinvent. I have to laugh a little seeing your reference to Mecanum wheels and your post being dated 6 hours ago. 12 hours ago, I rewatched the Star Trek reboot film. In it, there is a scene where the characters are all loading into shuttles to head off to their assignments. In the background, we are supposed to be impressed with the technical advancement of the machinery in view, e.g. how something as familiar as a forklift has "futuristic" details like strange wheels. And those wheels on that forklift are Mecanum wheels. In-story, that makes them something like ~300 year old technology.

fizlebit 1y ago

People say don't reinvent the wheel usually in a business context because writing from scratch is usually a lot more work than using existing technologies. Sure reusing technologies is also a lot more work than you would expect because most things suck (to different degrees), but so will your newly minted wheel. Only after a lot of hard lessons will it suck less, if at all. That said there are also contexts in which the existing system that was built sucks so bad that rewriting it usually a boon, even if the new wheel sucks, it sucks less from the start. You at a minimum should engage with the existing wheels and their users to find the ways in which they do and don't work. In your own time I think it is great to tinker, pull apart, assemble your own things. Every Jedi makes her own light saber right?

Derbasti 1y ago
Especially at work, I find existing solutions often lacking. We tend to overestimate the complexity of reinventing many things, and underestimate the cost of ill-fitting abstractions. In particular, Google-scale frameworks are usually harmfully over-engineered for smaller companies. Their challenge is solving the Google scale, not the problem at hand. At the same time, their complexity implies that a small-scale solution will likewise require a hundred-programmer team to implement. But I find that far from the truth. In fact, many problems benefit from a purpose-built, small-scale solution. I've seen this work out many times, and result in much simpler, easier-to-debug code. Google-scale frameworks are a very bad proxy for estimating the complexity of a task.
pzo 1y ago
This. Reinventing the wheel in business context IMOH should be only if: - you can afford it (money) - you have enough time or your customer can wait - provide significant benefit to you or your customers (have nothing better to do) - you don't have fierce competition in your domain - you are pretty much retired (or could) and treating it more like art/craft/passion project I compare it with building some custom made designer house and furniture. Many would want that, only some can afford it, even less will pay for it.

Zk_one 1y ago

[dead]

lukaslalinsky 1y ago

When you have a niche problem, you can usually reduce it in scope to such level, that you can make significantly better solution than trying to adapt some existing technology. It's not going to be universal, but for your niche problem, it can be much more suited. Back in 2010, I started an open source project for identifying audio files based on fingerprints. I specifically designed everything, so that in the end I need to do super fast i32->i32 lookups on scale. There were many inverted indexes, but they are usually for text search, which has a lot of overhead I don't need. I ended up writing a completely custom solution, and it allowed me to scale to millions and millions of fingerprints on such small servers that it was unimaginable to anyone who ever ran audio fingerprinting system before.

sireat 1y ago

As you get older, you have to become much pickier which if any wheels to reinvent. As others said reinventing the wheel is fantastic for learning, but not so for production / real life stuff. So for example implementing your own transformers from scratch - great for learning but for 99% it would not meaningfully change how you use LLMs for mundane things. So only when the domain is really really meaningful to you, you could consider reinventing the wheel and even then do not expect any immediately payoffs. Those 4000 weeks pass by awfully quickly. You have to pick your battles / wheels.

jaza 1y ago

Valid points in the article and in many of the comments here. BUT: taken to the extreme, "yes, reinvent the wheel!" quickly becomes NIH ("not invented here") syndrome, which I've seen one too many times in enterprise stacks, as I'm sure plenty of you folks have too. We don't need no stinkin' wheels from the OUTSIDE! I think every codebase needs a healthy and pragmatic balance of "this particular wheel we can and should build ourselves, and it'll work better (for us at least!) than any other wheels out there" vs "there is a standard wheel for this, 10 million other horse-and-carriages out there use the same wheel, it's not worth us using a non-standard wheel for this thing".

sylware 1y ago

It is interesting to do it, if it significantly simplifies and goes better to the point. Often, it is to give a variant proposal to something, rarely a bad thing. For, instance in software, alternative implementations are somewhat critical. It is actually a necessity "in the current economy" in order to sanely "work".

bullen 1y ago

When people say "don't reinvent the wheel" they really mean to say "don't copy the wheel". Reinvent means changing something, hopefully for the better: http://move.rupy.se/file/wheel.jpg http://move.rupy.se/file/wheel.jpg

kovac 1y ago

In the context of software, I wonder what would qualify as a wheel. I'd say implementations of standards like protocols, BLAS, etc probabaly are wheels and not trivial to reinvent. Would you consider something like Kubernetes, Docker, web browsers, web frameworks as wheels? I can't help but think the software quality would be much higher if the latter set wasn't considered as wheels and we tried to reinvent them often.

roes9627 1y ago

well i don't disagree so long as you have the time and your manager isn't rushing you to deploy that feature "ASAP" ;)

SwtCyber 1y ago

Sometimes the value isn't in creating something new for the world, it's in creating something new for yourself... I like it

tobr 1y ago

”Reinventing the wheel” is a misguided idea in the first place, because the invention of the wheel was really the invention of the road. So, it’s a phrase that in more ways than one suggest that you have no idea what invention is about.

didgetmaster 1y ago

Much of the bloated and inefficient code out there is the result of simply pulling something off the shelf and using it, just because it 'kind of' does what you need. Nevermind that a much simpler and efficient piece is possible, we have to ship ASAP so don't bother to spend any time on it. Include a whole set of dependencies just because we need a function or two in a huge library or framework. Worry about optimizations later (i.e. never).

ernestohegi 1y ago

How do you explain this to product owners in economic terms?

newExampleUser 1y ago

[flagged]

tiou 1y ago

In deep learning, gradient descent often gets stuck in local optima. While these points may not be perfect, they represent workable solutions given the current landscape. Similarly, existing “wheels” in software development are like these local optima—well-established solutions that work well in many cases but might not fit every unique scenario. Reinventing the wheel can be seen as an attempt to escape these local optima, exploring new approaches that better suit specific needs or constraints. This process involves effort and risk, just like tweaking optimization parameters in training, but it can lead to innovative and more tailored solutions. So, rather than blindly accepting existing solutions, sometimes it’s worth challenging them and trying to find a different path—just as in deep learning, where escaping local optima can improve model performance.

mppm 1y ago

> Note: When I say “wheel” throughout this post, please replace it with whatever tool, protocol, service, technology, or other invention you’re personally interested in. How did we sink this low?