3 ms·

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 vi

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.
        averagefluid 1y ago
        Market-based hypothesis is that the person erecting the fence incurs costs and if the expected value of the fence isn't higher than the cost of erecting it, it wouldn't have been erected in the first place. Of course mismanagement happens but the implied value of understanding why the fence was erected is to understand the expected value it would bring and understand the problem it was trying to solve. This does not imply that it should have been erected, just that there were others before you trying to solve a problem and if they're failing it's important to know why so you don't fail in the same way.
    - dclowd9901 1y ago
      It's funny. I had a similar analogy with some legacy systems recently. No one seemed to own or know where the data egressed to or whether it was even used anymore. But it was also low-value data and even in the worst case we surmised the most we'd do is anger someone in marketing briefly. I think so long as you can ascertain that the stakes are low, this is a good tactic.
- throwaway173738 1y ago
  The other 1% does it because the original wheel constrains them to an inferior approach that doesn’t work for their employer.
rTX5CMRXIfFG 1y ago
It's not really the best way to learn because it's the most expensive and time-consuming. What needs to be learned just needs to be well-documented and possible to tinker with, and clarity of communicating knowledge is a problem on its own, but you shouldn't have to build the whole thing from scratch.
- grg0 1y ago
  That sounds like learning something only very superficially. Rewriting from scratch is the only way to really learn any topic of non-trivial depth and complexity.
  - rTX5CMRXIfFG 1y ago
    It's not necessarily superficial learning. If you want to learn math, you'd be crazy to rewrite the rules of math just to learn it---you'd be better off with a good teacher and constant practice instead of building the theorems and formulas yourself, or you'll never finish learning math in your lifetime. Same can be said of learning a large inherited codebase. If you're assigned to a large piece of functionality and you need to understand it, your first instinct shouldn't be to rewrite the whole thing from scratch just to understand it; it should be to either read the code and documentation, or if those are impossible to comprehend, ask around what it's supposed to do, maybe even write tests to get a general sense of the behavior. I don't expect programmers to be cognitive psychologists here but the thing about learning is that you must do a "progressive overload" of complexity as you go, which is why building on top of what exists is the best way to go. You get a general idea first of what something is supposed to do, and then when you're good enough, that's when you can work backwards to building something from scratch where all the complexity at lower levels of abstraction wouldn't be too much for your brain to handle. Starting with a large amount of complexity will impair your learning and only discourage you.
    - christophilus 1y ago
      Different people learn differently. I learned computer science by first learning low-level languages, and then moving up the abstraction tree. Many go the opposite direction. Personally, I’m a fan of learning by doing. Reinventing the wheel works better for me than just about anything I’ve tried.
dennis_jeeves2 1y ago
>it's often not viable to explore them given deadlines and other constraints True for life in general. We have limited lifespans. Aging and death really are the great grand daddy of all problems.

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.
      - averagefluid 1y ago
        Market-based hypothesis is that the person erecting the fence incurs costs and if the expected value of the fence isn't higher than the cost of erecting it, it wouldn't have been erected in the first place. Of course mismanagement happens but the implied value of understanding why the fence was erected is to understand the expected value it would bring and understand the problem it was trying to solve. This does not imply that it should have been erected, just that there were others before you trying to solve a problem and if they're failing it's important to know why so you don't fail in the same way.
  - dclowd9901 1y ago
    It's funny. I had a similar analogy with some legacy systems recently. No one seemed to own or know where the data egressed to or whether it was even used anymore. But it was also low-value data and even in the worst case we surmised the most we'd do is anger someone in marketing briefly. I think so long as you can ascertain that the stakes are low, this is a good tactic.
throwaway173738 1y ago
The other 1% does it because the original wheel constrains them to an inferior approach that doesn’t work for their employer.

rTX5CMRXIfFG 1y ago

It's not really the best way to learn because it's the most expensive and time-consuming. What needs to be learned just needs to be well-documented and possible to tinker with, and clarity of communicating knowledge is a problem on its own, but you shouldn't have to build the whole thing from scratch.

grg0 1y ago
That sounds like learning something only very superficially. Rewriting from scratch is the only way to really learn any topic of non-trivial depth and complexity.
- rTX5CMRXIfFG 1y ago
  It's not necessarily superficial learning. If you want to learn math, you'd be crazy to rewrite the rules of math just to learn it---you'd be better off with a good teacher and constant practice instead of building the theorems and formulas yourself, or you'll never finish learning math in your lifetime. Same can be said of learning a large inherited codebase. If you're assigned to a large piece of functionality and you need to understand it, your first instinct shouldn't be to rewrite the whole thing from scratch just to understand it; it should be to either read the code and documentation, or if those are impossible to comprehend, ask around what it's supposed to do, maybe even write tests to get a general sense of the behavior. I don't expect programmers to be cognitive psychologists here but the thing about learning is that you must do a "progressive overload" of complexity as you go, which is why building on top of what exists is the best way to go. You get a general idea first of what something is supposed to do, and then when you're good enough, that's when you can work backwards to building something from scratch where all the complexity at lower levels of abstraction wouldn't be too much for your brain to handle. Starting with a large amount of complexity will impair your learning and only discourage you.
  - christophilus 1y ago
    Different people learn differently. I learned computer science by first learning low-level languages, and then moving up the abstraction tree. Many go the opposite direction. Personally, I’m a fan of learning by doing. Reinventing the wheel works better for me than just about anything I’ve tried.

dennis_jeeves2 1y ago

>it's often not viable to explore them given deadlines and other constraints True for life in general. We have limited lifespans. Aging and death really are the great grand daddy of all problems.