4 ms·

This is not a popular opinion, but I think you should always rewrite the wheel. The reason is simple, the product you are building cannot be more interesting th

by bullen 7y ago

This is not a popular opinion, but I think you should always rewrite the wheel. The reason is simple, the product you are building cannot be more interesting than the technology that lies under it. If you rewrite that, you will have to learn how things really work. And only when you do that, can you improve the fundamentals.

wpietri 7y ago
To me the flaw in this approach is that we have finite time and attention. I'm all for rewriting something when that something has the potential to radically improve what I'm building. But if we are busy rewriting everything else, we may never get to the one thing that delivers the most value. As an example, if I'm building some new piece of SaaS that has an API, I could write my own JSON parser, my own HTTP server, my own network stack, my own OS. Heck, I could eventually learn how to make my own servers, my own processors. But I'd be comfortably dead before I learned how to do all those things as well as off-the-shelf components deliver for a SaaS API. Instead I'd rather spend my time on activities that are more valuable to my users. If one of those things turns out to writing a custom JSON processor, sure, I'll do it. But if the only purpose in me doing that is to learn something, then I shouldn't be jamming my educational experiments into a production system that doesn't need them. I've had to clean up too much of other people's flavor-of-the-month experiments to want to inflict that on whoever maintains my code next.
jniedrauer 7y ago
Writing something new comes with tremendous future cost. 99% of the functionality will be pretty quick to implement. But 3 years later, you'll still be fixing edge cases and you'll have to keep the documentation up to date if you ever want to hire other developers to work on it. Writing something from scratch just because you want to understand it is fine. But you should think long and hard before actually using the new thing you just wrote in production code.

by bullen 7y ago

wpietri 7y ago

To me the flaw in this approach is that we have finite time and attention. I'm all for rewriting something when that something has the potential to radically improve what I'm building. But if we are busy rewriting everything else, we may never get to the one thing that delivers the most value. As an example, if I'm building some new piece of SaaS that has an API, I could write my own JSON parser, my own HTTP server, my own network stack, my own OS. Heck, I could eventually learn how to make my own servers, my own processors. But I'd be comfortably dead before I learned how to do all those things as well as off-the-shelf components deliver for a SaaS API. Instead I'd rather spend my time on activities that are more valuable to my users. If one of those things turns out to writing a custom JSON processor, sure, I'll do it. But if the only purpose in me doing that is to learn something, then I shouldn't be jamming my educational experiments into a production system that doesn't need them. I've had to clean up too much of other people's flavor-of-the-month experiments to want to inflict that on whoever maintains my code next.

jniedrauer 7y ago

Writing something new comes with tremendous future cost. 99% of the functionality will be pretty quick to implement. But 3 years later, you'll still be fixing edge cases and you'll have to keep the documentation up to date if you ever want to hire other developers to work on it. Writing something from scratch just because you want to understand it is fine. But you should think long and hard before actually using the new thing you just wrote in production code.