> > but trust me, re-writing code is way easier than writing it from scratch
> Not always true, and not even often true.
In my experience, virtually always true. Just rereading the code you wrote before will bring back the understanding you had when you wrote it (unless you intentionally wrote obfuscated code, I suppose?), and it'll be immediately obvious to several-years-on you what the shortcomings were of that idea. If you have the time, a full rewrite almost always turns out to be better code than the old version, as long as you can hold off on trying new experiments in the process.
You can always take the experience, but often the old code exists in such a misguided architecture that it is better to scrap it vs. unwind multitudes of bad uninformed decisions (b.c. you know better now!).
Re-writing code is actually almost always harder than writing it from scratch, but we do it for other benefits: interoperability with legacy components, legacy of expected behavior (warts and all), risk (the old code is debugged), and culture (programs in the team know that code). But if you don't have those requirements, you will often come out behind in rewriting all code rather than going with a green field.
It also depends on whether the work one is doing is cutting edge (lots of experimentation and learning required) or basic dev work over relatively well known concepts.
> Not always true, and not even often true.
In my experience, virtually always true. Just rereading the code you wrote before will bring back the understanding you had when you wrote it (unless you intentionally wrote obfuscated code, I suppose?), and it'll be immediately obvious to several-years-on you what the shortcomings were of that idea. If you have the time, a full rewrite almost always turns out to be better code than the old version, as long as you can hold off on trying new experiments in the process.