There's nothing worse than realizing that you spent a whole bunch of time reimplementing something someone had already built when you could have simply taken a fraction of that time to understand why it was the way it was and, if applicable, to extend it to do whatever else you needed.
This also goes for looking for existing libraries to implement a feature before deciding to write your own. You still might need to write your own if you don't find something that fits, but sometimes you can save yourself a ton of work.
The only saving grace for having wasted all that time is learning the lesson that it's a waste of time and being able to apply that lesson usefully going forward. It's possible to go too far down that road and be too afraid to mess with existing code, but that line is actually in a very different place than I thought it was 10-15 years ago.
There's nothing worse than realizing that you spent a whole bunch of time reimplementing something someone had already built when you could have simply taken a fraction of that time to understand why it was the way it was and, if applicable, to extend it to do whatever else you needed.
There is something far worse. Spending years of your life to maintain a software version of Rube Goldberg Machine that performs mostly trivial things, but has insane accidental complexity.
At least when you re-implement something (even if it's been done before), you gain a better understanding of general ideas behind it.
Yes, but if you're going to replace it, then you really, really want to take the time to understand why it was the way it was.
Sometimes, you really do run across things that could never make any sense to anyone who knew better, like the famous Daily WTF example where someone created a website for a restaurant by printing out the page design for the paper menu, laying it on a wooden table, taking a picture of it, and uploading the picture. But other times -- much more often, in my experience -- you run across hidden technical challenges and limitations that led to what look like really stupid decisions until you understand the real motivation. And even when there were some really stupid decisions, it's often better to leave the system largely intact while you incrementally fix the stupid parts.
And, as I said before, sometimes it really does make sense to go in and start over. It's just that the line for when it's warranted may not be where you think it is.
As far as learning things go, providing your own implementation to solve a problem can be a great learning tool. Likewise, writing your own compiler, database, or web server can be an absolutely fantastic means for understanding these tools better. But it will rarely be the best means of solving a problem that requires a database-backed web application.
Reuse production-proven existing code and tools wherever you can when you're on the clock for a job or building a company, and teach yourself how things work on the side. If you build something so good that it's worth swapping in for the original and going through all the steps to bulletproof it for production, then awesome. If not, then you've still learned what you cared about learning.
There's nothing worse than realizing that you spent a whole bunch of time reimplementing something someone had already built when you could have simply taken a fraction of that time to understand why it was the way it was and, if applicable, to extend it to do whatever else you needed.
This also goes for looking for existing libraries to implement a feature before deciding to write your own. You still might need to write your own if you don't find something that fits, but sometimes you can save yourself a ton of work.
The only saving grace for having wasted all that time is learning the lesson that it's a waste of time and being able to apply that lesson usefully going forward. It's possible to go too far down that road and be too afraid to mess with existing code, but that line is actually in a very different place than I thought it was 10-15 years ago.