Greenfield projects are 1% of a SE job. IME “the code is crap, we need to start again” really means “I don’t want to (or worse, can’t) read source code that isn’t mine”. Reading and understanding someone else’s code then making and executing a plan to improve it is a much more valuable skill. If you’re always working on greenfield projects, you’ll never understand what it means to build software with longevity.
> IME “the code is crap, we need to start again” really means “I don’t want to (or worse, can’t) read source code that isn’t mine” understood. but sometimes the code really is crap, and possibly a danger to the business.
For example, one thing I look for is when the model can not explicitly express all of the states that we now need, and as a result the code has developed various “hacks” that try and simulate the additional states. This code tends to look like “guesses” or “assumptions”. For example, “if not red than blue” or “if no records than user is still on step one”. I tend to see developers spending hours in that kind of code, trying to confirm that the assumption is still always the correct one to make, or trying to shoehorn in another state, and it’s just a horrible time-suck. Improving the model at this point generally pays off in time saved puzzling.