Being closed to the possibility of rewriting a project is one of the worst decisions advanced-intermediate engineers make. How much technical debt has accumulated? How many future features/changes need to be made? How long does it take just to maintain the current feature-set?

If a re-write saves more time than it takes, then it should be considered. If it takes you a week to implement something that should be done in a day, and you realize that you'll be doing lots of those things over the course of the next few years, it's probably worth considering a re-write. It's not a solution to every problem, and it's probably done more often than it's not, but there are certainly times when it pays to do it. It's easy to have simple rules that say don't do things. It's much harder to make the best decision for the business. Just because some businesses in the past have made the wrong decision with regards to re-writes doesn't mean it's always wrong.

I'm not saying you should always rewrite your code in a professional setting. In the scope of my previous comment, I was definitely considering personal projects.

That said, when systems need to be re-engineered, completely thrown out and re-written, or a new feature needs to be cranked out to meet a business need, the developers who can design and create large coherent systems quickly is irreplaceable or very expensive. Constantly throwing your code out gives you this valuable experience.

> Completely rewriting things is one of the worst decisions an intermediate engineer makes. That's what killed Netscape.

This is commonly trotted out to discourage re-writes, but how does that square with another piece of common advice: "build one to throw away" ?

I'm genuinely curious, and I'm not trying to pick on you specifically. There are just many different situations where one or the other makes sense, so I don't think it's so cut and dried.

It's not cut and dried, but a good guideline is this:

If you've written a program, but it doesn't work yet, and you've realized you made major architectural mistakes or whatever, feel free to rewrite from scratch.

If you've written a program and it's been in real use for a while, solving real problems for a lot of happy users, that means it embodies a lot of knowledge that will be difficult to re-create from scratch; in that case, think very carefully before embarking on a rewrite, and look hard for a way forward that will preserve that knowledge.

there is a big difference between rewriting netscape and rewriting the time tracking software for a 100 person company. Netscape was a very large, complicated product written by a lot of developers. Most software isn't like that. I'm not saying that learning from netscape's mistake isn't valuable but there is an important distinction to be made. Rewriting software can often get rid of a lot of cruft and edge cases caused by developers not following YAGNI.