Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wheel Reinventor’s Principles (2024)

tobloef.com

Post reply on HN
Print view View original

61–70 of 101 posts

Re: Wheel Reinventor’s Principles (2024)

#61

Post by rahkiin »

sunrunner wrote: post #34

Like 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. T…

We re-invented the wheel quite some times.

Stone, then wood, then wood with spokes, then wood with spokes and iron trim, then we eventually added rubber, rubber tubing, then all metal spoke with rubber. For Mars rovers they made new types of air-less wheels.

The saying ‘do not reinvent the wheel’ is just silly

Re: Wheel Reinventor’s Principles (2024)

#62

Post by wcfrobert »

I find that for me to deeply understand something, I have to reinvent it. There's SO many nuance not captured in textbooks or papers. I reminds me of the feeling of attending lectures by great teachers. Everything makes so much sense until you start the homework assignment.

Re: Wheel Reinventor’s Principles (2024)

#63

Post by wcfrobert »

sunrunner wrote: post #34

Like 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. T…

It's probably more interesting to reinvent things on the lower abstraction layers, otherwise we're just reinventing design decisions.

Re: Wheel Reinventor’s Principles (2024)

#64

Post by sunrunner »

rahkiin wrote: post #61
sunrunner wrote: post #34

Like 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. T…

We re-invented the wheel quite some times. Stone, then wood, then wood with spokes, then wood with spokes and iron trim, then we eventually added rubber, rubber tubing, then all metal spoke with rubber. For Mars rovers they made new types of air-less wheels. The saying ‘do not reinvent the wheel’ is just silly

Re-invented or re-implemented? The design was always the same just the materials have changed (and maybe there's something about motor racing and new wheels being available every year...)

Re: Wheel Reinventor’s Principles (2024)

#65

Post by strongpigeon »

> [...] Be wary of abstractions made for fabricated use cases.

Very well put and I would argue this applies to general software development. This is one of the biggest difference between my freshly-out-of-college self and me right now and something I try to teach engineer I'm trying to grow into "seniors".

Too many time have I seen a lot of wasted efforts on trying to build hyper flexible components ("this can do anything!") to support potential future use cases, which often never come to be. This typically results in components that don't do that much and/or are hard to use.

Design your components as simply as you need them, but no simpler. This typically gives more flexibility to grow rather than accounting for currently-not-needed use cases.

Re: Wheel Reinventor’s Principles (2024)

#67

Post by bee_rider »

jstimpfle wrote: post #57
sunrunner wrote: post #34

Like 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. T…

The usual allegoric rebuttal is to show how many types of wheel there are, and how wheels have improved over time. The wheel as a basic concept is to mount a rotating circular shaped thing on a platform for moving. The first wheels were made of wood, at some point spokes were introduced, then other materials. Many more innovations (many of them mutually exclusive) are required to realize a formula 1 car, or a ralley…

There is so much work put into bicycle wheels, and you can carefully select a wheel depending on if you are building a time trial bike, a regular road bike, a commuter bike, mountain bike…

If we could create physical things as easily as software, we’d absolutely see bicycle hobbyists and certainly little shops designing their own wheels.

Re: Wheel Reinventor’s Principles (2024)

#68

Post by intalentive »

01HNNWZ0MV43FF wrote: post #28
didgetmaster wrote: post #20

Reinventing 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

I found this. There's also a demo. Good points. https://didgets.substack.com/p/where-did-i-put-that-file

Re: Wheel Reinventor’s Principles (2024)

#69

Post by bch »

skvmb wrote: post #52
sunrunner wrote: post #34

Like 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. T…

Sometimes when reinventing the wheel, you realize that pot-holes suck. Learn to appreciate the wheel and reinvent the road. Learn to appreciate the road and reinvent the rocket. I guess I'm walking home.

This is well-put. I think it speaks to "its the journey, not the destination", not learning to ski by only reading books, and Chesterson's Fence[0], off the top of my head.

[0] https://fs.blog/chestertons-fence/

Re: Wheel Reinventor’s Principles (2024)

#70

Post by add-sub-mul-div »

strongpigeon wrote: post #65

> [...] Be wary of abstractions made for fabricated use cases. Very well put and I would argue this applies to general software development. This is one of the biggest difference between my freshly-out-of-college self and me right now and something I try to teach engineer I'm trying to grow into "seniors". Too many time have I seen a lot of wasted efforts on trying to build hyper flexible components ("this can do any…

Another good way I've seen it put is, the difference between underengineering and overengineering is that you can fix underengineering.
Post reply on HN