Dealing with your own legacy

Keeping with the theme of learning... legacy.People who start programming right out of college typically get assigned a job of dealing with the legacy code in whatever company they wind up in.Everyone looks at the code and wonders how it ever got that screwed up in the first place."Other companies must be better than the cesspool that we have here!"Except it's not.In classes ever project stands alone. You code something the prof tells you, you hand it in, then you promptly forget about it. As the project is being worked on if you need to refactor, go for it! -- as long as it gets done it's all good!Then you get into the real world.Every day you sit down to the keyboard and write a line of code, you create tomorrows legacy. And tomorrow you create next weeks. Next week: next month... and so on down the line.That's one thing you don't get in a any school I know of. The realization that everything you do will affect you later on.But overcorrecting to not create legacy also has it's problems. Perfection costs a lot.Over time, and through making the wrong decision over and over again, you learn to strike the right balance between too good and not good enough.Sometimes though, as with the case of something like Harley Davidson, it's a question of keeping your legacy since people won't buy anything without that.