This is what I want to do as an engineer, but I know damn well it's a waste of time and money.
That's why I do it for fun on weekends
Wheel Reinventor’s Principles (2024)
31–40 of 101 posts
Re: Wheel Reinventor’s Principles (2024)
#32I'm definitely a wheel re-inventor (in the educational and entrepreneur sense), and I've come across the same learning points myself. Recently, I just started blogging about my little wheels, and I think its been one of the most satisfying aspects of working on a project!
Re: Wheel Reinventor’s Principles (2024)
#33In scientific software development "don't want to reinvent the wheel" is an oft-repeated mantra that I like to push back on when I hear it. To be fair it's often used in the context of "we'd rather/like to collaborate", rather than an appeal to use "that exact thing".
Re-inventing things independently in parallel (parallel evolution analogies) is perhaps a strong indication that something interesting is going on. How do we know we got it "right" if we don't converge independently? If we invent a square wheel, and stopped because "wheel", we'd be in a horrible place. Science is a process, the process of reinventing is a great way to realize new things, and to train, at a low level, scientists. I suspect the process of re-inventing is also important in building out our (long term) ability to depend on our "gut feelings", thus providing the ability to nudge us to experiment along one path or another.
[Edit ... all things the article mentions.]
Re: Wheel Reinventor’s Principles (2024)
#34Like every single software development principle, this phrase really needs to be explained with more context and considered with more subtlety than the usual "It's best practice" advice, for a number of reasons (some of which are stated in the article) of which I think the following two are the most important:
Firstly, if you want to actually understand how the 'wheel' is invented then yes, you should re-invent it. The process of re-invention involves discovering what actually goes into some of the tools you use. Even if you never use your re-invented wheel in public (often advisable), the process of learning is invaluable in understanding the tools you do use.
Secondly, however, what wheel are we even talking about? The wheel is a timeless design, seemingly perfectly suited its task. The software libraries and tools that are usually picked as targets for 'not re-invention' are not wheels. They're higher level abstractions that pre-suppose certain ways of working. There's no timeless design here, just a bunch of arbitrary desicions about how something should work at a higher level with some amount of the decision making you'd have to do without it already done. Is this a bad thing? Of course not. But understanding that all of the 'wheels' are just this and are not magical black boxes that can't be understoor or shouldn't be looked at is important.
There are good times to not immediately go and re-implement *and publish* existing tools (emphasis on the publish, you should do things for learning), but understaning why you're choosing to do or NOT do a 'reinvention' is crucial.
Re: Wheel Reinventor’s Principles (2024)
#35I'll add "reduce code size and complexity" to the list of benefits. A python library to calculate a simhash, or track changes on a django model, or auto generate test fixtures, will often be 90% configuration cruft for other usecases, and 10% the code your app actually cares about. Reading the library and extracting and finetuning the core logic makes you responsible for the bugs in the 10%, but no longer affected by…
Hard agree. A library should not inflict complex use cases' complexity on simple use cases, but sometimes they do, either because they're poorly designed or because they're overkill for your use case. But often I see pain and complexity excused with "this is the library that everybody else uses." Sometimes a simple bespoke solution minimizes costs compared to the complexity of using a massive hairball with a ton of p…
The big caveat is a big one. Choose your battles wisely!
There are plenty of things that look simpler than an established library at first glance (I/O of specialized formats comes to mind quickly). However, a lot of the complexity of that established library can wind up being edge cases that you actually _do_ care about, you just don't realize it yet.
It's easy to wind up blind to maintenance burden of "just a quick add to the in-house version" repeated over and over again until you wind up with something that has all of the complexities of the widely used library you were trying to avoid.
With that said, I still agree that it's good to write things from scratch and avoid complex dependencies where possible! I just think choosing the right cases to do so can be a bit of an art. It's a good one to hone.
Re: Wheel Reinventor’s Principles (2024)
#36But should I tell my boss that I'm reinventing everything?
colleague of mine wrote a json parser in sql when the rdbms already had a json parser... guess where all the errors came from
Re: Wheel Reinventor’s Principles (2024)
#37There's a big difference between "reinventing the wheel" and simply making your own wheel. People often conflate the two.
e.g. making your own static site generator is not reinventing the wheel. It's making your own wheel, which is a perfectly cromulent use of time.
Re: Wheel Reinventor’s Principles (2024)
#38A lot of time I find myself reinventing the wheel is because of some framework that has decided that inverted catenary flooring is the future and their provided wheels are excellent for going in the standard use case direction.
Re: Wheel Reinventor’s Principles (2024)
#39Re: Wheel Reinventor’s Principles (2024)
#40Reinventing the wheel often means breaking things. Innovation often requires getting rid of backwards compatibility. The status quo is promoted by those who have invested in it, so disrupting it can be met with fierce resistance. When I tell people that file systems are antiquated and need to be replaced with something much better; I often get strong push back. This is a wheel that I have been reinventing for some ti…
Do you have a blog about replacing file systems with something much better? I'm curious what you've tried so far
My blog is listed in my profile. Didgets.substack.com has many blog entries.