[HN Gopher] Reinvent the Wheel
___________________________________________________________________
Reinvent the Wheel
Author : zdw
Score : 112 points
Date : 2025-05-24 20:05 UTC (2 hours ago)
(HTM) web link (endler.dev)
(TXT) w3m dump (endler.dev)
| moron4hire wrote:
| 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 wrote:
| I'm sorry but you're mistaken. The wheel was invented thousands
| of years ago.
| hoppp wrote:
| 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 wrote:
| 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 wrote:
| You can reinvent the wheel for a specialized niche case but just
| dont expect many people to use it.
| mcnamaratw wrote:
| 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 wrote:
| If you invent someting better, you can get reward, lots of
| examples out there.
| mcnamaratw wrote:
| Sure. But inventing something better is not reinventing the
| wheel. Those are two completely different activities.
| nssnsjsjsjs wrote:
| It doesn't have to be not better though. The wheel
| reinventor has hindsight.
| baxtr wrote:
| "Sometimes it's a good idea to reinvent the wheel" would have
| been a better title.
| nssnsjsjsjs wrote:
| Oh I totally assumed this applied to passion projects, making
| your own K8s on weekends kind of thing.
| wcfrobert wrote:
| 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 wrote:
| 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.
| zero-sharp wrote:
| 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 wrote:
| 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.
| begueradj wrote:
| 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 wrote:
| 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 wrote:
| That's true for frameworks but not good libraries.
| zzo38computer wrote:
| I also agree to avoid adding complexity through unnecessary
| dependencies.
|
| > if a library is popular, it contains huge amounts of code
| that just isn't relevant to your use case.
|
| It is true that many libraries do contain such code, whether
| or not they have dependencies. For example, SQLite does not
| have any dependencies but does have code that is not
| necessarily relevant to your use. However, some programs
| (including SQLite) have conditional compilation; that
| sometimes helps, but in many cases it is not suitable, since
| it is still the same program and conditional compilation does
| not change it into an entirely different one which is more
| suitable for your use.
|
| Also, I find often that programs include some features that I
| do not want and exclude many others, and existing programs
| may be difficult to change to do it. So that might be another
| reason to write my own, too.
| jfengel wrote:
| Unfortunately, if you depend on any libraries, there's a
| decent chance one of them depends on some support library.
| Possibly for just one function. And then your build tool
| downloads the entire Internet.
| thfuran wrote:
| That depends a lot on your language / build system. The
| easier it is to add a dependency, the more likely that is
| to be how they work, broadly speaking.
| rjsw wrote:
| A ruby application that I will soon need to use downloads
| 227 packages.
| bitwize wrote:
| "Never roll your own crypto" usually means "never devise your
| own crypto algorithms". Implementing an established algorithm
| yourself is OK _provided_ you can prove your implementation
| works correctly. And... well, as Heartbleed showed, that 's
| hard even with established crypto _libraries_.
| anyonecancode wrote:
| Less "reinventing" the wheel and more "uncovering the wheel."
| turtleyacht wrote:
| > 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 wrote:
| 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.
| Blikkentrekker wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| megadragon9 wrote:
| 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
|
| [2] https://github.com/workofart/ml-by-
| hand/blob/main/examples/c...
|
| [3] https://github.com/workofart/ml-by-
| hand/blob/main/examples/g...
| richardjennings wrote:
| 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 wrote:
| Previously at HN https://news.ycombinator.com/item?id=43434730
| priorityfill wrote:
| 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).
| awinter-py wrote:
| 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 wrote:
| 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 wrote:
| I'll bite! What wheel is this?
| Archelaos wrote:
| Probably what he links to on his profile page.
| weaksauce wrote:
| got to imagine it is this https://github.com/boricj/ghidra-
| delinker-extension
| boricj wrote:
| This wheel: 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.
| elorant wrote:
| In my almost 15 years in this community this is the first
| comment where I don't have a fucking clue of what is
| described.
| OtomotO wrote:
| 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 wrote:
| closely related: https://news.ycombinator.com/item?id=43434730
| random3 wrote:
| And the even more general advice: "First, break all the rules"
| (not (necessarily) the book).
| sfpotter wrote:
| So many bitter and jaded people in this thread.
| semiinfinitely wrote:
| 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 wrote:
| 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.
| mullingitover wrote:
| 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 wrote:
| 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 wrote:
| I guess it's more like an advice for personal wheels, not
| professional ones.
| Waterluvian wrote:
| 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 wrote:
| People that work at Radial, Michelin, Good Year, etc... probably
| are sick of hearing it.
| ppqqrr wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-24 23:00 UTC)